Workflows fit so naturally with the idea of composition. SwiftUI is of course completely composition based. SwiftUI is also completely unfriendly if you're handling workflows. Navigation stack modification is tricky at best and SwiftUI actually makes the whole problem of one screen having to know what is next far worse.

SwiftCurrent can step in, provide composable behavior with Workflows, and solve those problems and we're interested in giving a great user experience around management of this.

We know this milestone is successful when:

• We have an example app showcasing best practices (including testing) for SwiftCurrent with SwiftUI
• We have getting started documentation showcasing how to quickly get started with SwiftCurrent_SwiftUI
• The workflow by default is capable of proceeding and backing up, skipping screens, and handling the same flow persistences as UIKit
• Modal workflows in SwiftUI are supported
• Navigation workflows in SwiftUI are supported
• Workflows that switch between modal presentation and navigation stack presentation are supported
• Workflows can launch (modally) a navigation stack

Things we should think about, but maybe deserve their own milestone due to size:

• Workflows should help bridge between UIKit and SwiftUI where necessary
• It may be that you just use a UIHostingController
• It may also be that SwiftCurrent just handles it so that if I create a workflow that has FlowRepresentables that are UIViewControllers and different ones that are Views it "just works"