SwiftUI navigation solution

[VladIacobIonut]

Hello,

I was really impressed by the design you described as a solution for SwiftUI navigation here: https://quickbirdstudios.com/blog/coordinator-pattern-in-swiftui/. It is really impressive how it achieves decoupling while still being so comprehensive.

However I was just curious If you ever thought of a solution where you kept the current infrastructure xCoordinator for UIKit in place and port it to SwiftUI by creating UIHostingControllers which wrap our SwiftUI views instead. In this solution the SwiftUI views would still talk only to their viewModel which would still get a reference to our Coordinator. On a navigation action the coordinator would still use the prepareForTransition function to return a route to our SwiftUI View wrapped in a UIHostingController. Something like: .push(UIHostingController(DetailsView(viewModel: _)).

Maybe this solution brings some performance limitations with it and if you analysed it beforehand as well I would love to hear which ones are those.

As I'm sure you have far more expertise on this than I do I would also like to know what you think of this alternative solution. Nevertheless the original one I think it's very innovative!

Cheers.

[pauljohanneskraft]

Hello - thank you for your kind words.

I have thought about this approach before, but I have not dived deeper, since it would probably only really be a intermediate solution until the transition to full-on SwiftUI is complete. I'm not sure, whether one would want to have declarative and imperative/OOP UI code in one project for an extended period of time (unless for special cases, where a library would only provide UIKit components, for example).

I do not see any performance limitations, that would be brought with this, since that is pretty much what SwiftUI is doing in the background as well. The only real performance limitation would possibly be UIHostingController itself by using AnyView instead of being able to use diffing for view changes. I have unfortunately no further insight into this - but I'd be happy to know more, if you have tested this already!

Thank you again for your kind words. I generally like the idea, if there is a large codebase that is not expected to be refactored as a whole, but SwiftUI should be used for individual screens. Once a full flow (i.e. all route cases) are fully converted to SwiftUI, I would probably also convert the coordinator to SwiftUI. However, I do not actually know, which challenges might arise with this.