Great video. Coordinators with Combine and MVVM are really powerful. Another approach would be to construct coordinators using factories, and delegate the responsibilities of navigation (e.g. pushing and popping) to a navigator class which gets injected into coordinators as a dependency.
This is pretty straightforward; the only difference in all of this is having to use UIHostingController instead of just instantiating a VC as normal. It's cool to have all the power of the old and well tested coordinator pattern with the quickness of SwiftUI instead of having to code 100 lines to build a UI screen with UIKit. Haha.
Brilliant content. I'm an old Android dev who is branching off into iOS (Kotlin Multiplatform) and this is invaluable. I have been hearing about "Coordinator" for years but never looked into it. I thought it was some esoteric abstract way to compose application flows. But it's literally the same pattern as our Fragment-based navigation, where Coordinator fulfills the same role as a Fragment! We have been using this for years in Android apps! Except we get this for "free" from Google as a part of their AndroidX library suite. This makes the switch all the more easy.
I just came over to a team that is in the process of planning to migrate their app to SwiftUI and Combine. Thanks for this! I'm still learning Swift (I have a C, Python and Kotlin background, so it's relatively familiar to me), but this is pretty close to a "middle-ground" for our current app and a full SwiftUI+Combine backend.
Hey! Karin, ,I just discovered your channel and you have really great content, you are a great teacher, i learned a lot with this video. Thanks for sharing your knowledge!
A great video! I see lots of people injecting the coordinator inside the ViewController or SwiftUI. Make views as dumb as possible only have an interface for input and output. The only small improvement I would make is the the naming of the callback from the view controller. Make the name agnostic to the navigation, it should be something like, didPressButton or didPressDetails e.t.c. Otherwise great video. 💙🚀
That was great thanks! We have been seeing inconsistencies with SwiftUI navigation in our Kotlin Multiplatform Application, which we finally solved using the Decompose library.
This is beautiful! Just the way I would use SwiftUI and UIKit together. I think SwiftUI navigation really sucks and this is a great way to have "imperative" navigation while also making it declarative and reactive using Combine. I also like how these coordinators not only abstract away the navigation, but also handle data flow and act in a way as a "view factory". Fantastic concept presented in the best way possible. Also I really like the example you showed in the video - it's both simple enough to not overwehlm the viewer and complex enough to show off the concept properly and also see the benefits of having unidirectional dataflow. Fantastic! Keep up the good work!
MVVM is the same as MVC, just all the code from view controller goes in model view. It does not separate anything. MVVM replaces massive view controllers with massive view models. The only valuable thing Model View can do is to format model data. So it is good as two-way value transformers. But people just add complexity adding Combine, Coordinator and so on, that increases time for understanding such code.
Oh my gosh. Your video is brilliant. I like it a lot. I just started coding and after this video I am definitely clear with Coordinator pattern. By the way use SWIFTUI with UIKIT is a brilliant idea.Thank you very much for this content. Like and subscribe.❤
I have noticed a few bugs (some show-stopping) with SwiftUI navigation that would be inconsistent between iOS versions on the app I am working on. I also had to go back to using UIKit behind the scenes for navigation. This is definitely a more elegant solution than what I am currently using.
Nice tutorial on using coordinators, combine, and view models in UIKit with a bit of SwiftUI. Also I like the explanation of benefits of using Coordinator pattern (an ViewModels). I"ve used these patterns about three years ago in a commercial App (all UKit). What's your thoughts of using coordinators in a pure SwiftUI app (no UKIt)? Something I've just started to think about. Do you think the major issue is navigation?
I am not sure how to implement the Coordinator pattern with SwiftUI. It is designed for UIKit. I did a test on the navigation for SwiftUI ua-cam.com/video/vL0w3kvng0o/v-deo.html. I really like to simplicity and state driven navigation. One of my main issues with SwiftUI is the navigation because in this area I cannot find nice work arounds for bugs. Also not much customisation: is it strange to ask for a way to change the font of a navigation bar title? This is probably a very common task.
Awesome video! There is only one thing that I don't really understand, why are we storing references to the child coordinators in the parent coordinator class ?
On the one hand this is a great way to get rid of the dependencies between views that NavigationLink creates by requiring an opaque type and get the navigation out of the VC...on the other hand it's going to huge pain in the ass if Swift projects are going to need UIKit navigation and SwiftUI views for the foreseeable future...
Nice video, I had to do something similar in my project, I like swiftUI a lot due to the speed up that it gives, but some bugs is very annoying, other than that I see a lot of performance issues with SwiftUI as well, my solution was to use UIKit for top level on everything, this also avoid some random redraws
Hello. I have a question about childCoordinators property. I've tried to comment all the lines with this variable and everything works as it should. Why do we need it? Other guides and articles also implement some methods to remove childCoordinators from parent's array when popping from them. Can you explain it somehow? Btw, thank you for the video!
I just have one question. How we will manage rest of Coordinator if we want to pass from FirstDetailView to OnotherView? Do we have to create ViewController again every section or we can continue just with NavigationStack?
Thanks. It was interesting to see a different method of achieving a clear separation of concerns in SwiftUI 👍 Combine ftw Would you please consider using dark mode in the future? I'm watching these on a big screen, and light mode burns my eyes :D
This is a really interesting use of combine, but it seems like it would be much better to have the orientation flow as a modal under the navigation controller
I really like your approach. The only downside (and its pretty big) is you lose custom environment injection in SwiftUI (either custom environment keys, or environment objects). So I guess in your approach, you would hoist that data to a shared state singleton or thread it through the view hierarchy? I dont like either of those solutions, but I dislike SwiftUI navigation more : D Sidenote: really great stuff on your channel. I'm getting a lot out of it, especially as a UIKit dev coming to SwiftUI.
Do you have a solution to this problem or think this can be solved by not ruining the concept of the Coordinator pattern? Also @Karin I would love to hear your thoughts on this. Great video and has really helped in my project.
Can you put up a link or show your code on your navigation that causes that second draw/navigate at the beginning (right side)? The only time I ever see that is when I break the basics of state updates, usually because I've made a horrible mistake in timing or nav-time updates to state. I'm just not sure how you got that to be a thing.
can someone please explain me how to transfer "hasSeenOnboarding" boolean state? i don't understand one thing : so in appCoordinator we create method which listen for the current state and depends on it load different flows: - 1.if user launch application for the first time it's goes up for "onboarding" flow...okay but how do actually we change the state of it while user end up looking for onboarding instructions? I understand that Karin created observable object on appCoordinator, but which trigger change the state? She just pass this property inside " OnboardingCoordinator init() " And in start method simply put true inside this object. where we add target or some action on done button of OnboardingView?
This might be a rare scenerio (and just a suggestion): can you add Objective-C view controller into this current structure, aka MVVM+C with SwiftUI View controller, UIKit View Controller, and Objective-C view controller? Some old project might be in the migration phrase and it does not tranalate its codebase to the Swift or SwiftUI fast enough.
good to see this comment, I just learned swiftui but havent done work with NavigationStack, Im aware of the problems it has cause ive been reading about it lol. Im gonna stick with UIKit for routing and SwiftUI for the rest
Great video Karin.. thank you for explaining the approach. Here instead of closers, isn't it better to just inject these coordinators inside the viewModels and then have those viewModels be injected in ViewControllers or Views. That way, from view or viewModel, we can directly call any methods on coordinators if need be,
I can't believe more and more people don't reverse migrate back to UIKit. My time with swiftui was abysmal. I feel like it is still some time away from the standard for large projects
![SwiftUI Tutorial: Typical errors with SwiftUI, the preview and how to fix them [Xcode 14]](http://i.ytimg.com/vi/w3eIH7sUM_k/mqdefault.jpg)
![SwiftUI Tutorial: Typical errors with SwiftUI, the preview and how to fix them [Xcode 14]](/img/tr.png)
Great video. Coordinators with Combine and MVVM are really powerful. Another approach would be to construct coordinators using factories, and delegate the responsibilities of navigation (e.g. pushing and popping) to a navigator class which gets injected into coordinators as a dependency.
This is pretty straightforward; the only difference in all of this is having to use UIHostingController instead of just instantiating a VC as normal. It's cool to have all the power of the old and well tested coordinator pattern with the quickness of SwiftUI instead of having to code 100 lines to build a UI screen with UIKit. Haha.
Precisely what I was looking for. The use of Combine fits well if you are listing to the Auth state and want to use coordinators.
Brilliant content. I'm an old Android dev who is branching off into iOS (Kotlin Multiplatform) and this is invaluable. I have been hearing about "Coordinator" for years but never looked into it. I thought it was some esoteric abstract way to compose application flows.
But it's literally the same pattern as our Fragment-based navigation, where Coordinator fulfills the same role as a Fragment! We have been using this for years in Android apps! Except we get this for "free" from Google as a part of their AndroidX library suite. This makes the switch all the more easy.
I just came over to a team that is in the process of planning to migrate their app to SwiftUI and Combine. Thanks for this! I'm still learning Swift (I have a C, Python and Kotlin background, so it's relatively familiar to me), but this is pretty close to a "middle-ground" for our current app and a full SwiftUI+Combine backend.
Hey! Karin, ,I just discovered your channel and you have really great content, you are a great teacher, i learned a lot with this video. Thanks for sharing your knowledge!
Amazing video, it's so well explained and helped me a lot to learn how to implement the coordinator pattern for navigation. Thank you so much ! :D
Amazing content always using swift best practices along with great explanations and absolute understanding!!! Thank you!!!!
very simple tutorial.It is only for beginners
A great video! I see lots of people injecting the coordinator inside the ViewController or SwiftUI. Make views as dumb as possible only have an interface for input and output. The only small improvement I would make is the the naming of the callback from the view controller. Make the name agnostic to the navigation, it should be something like, didPressButton or didPressDetails e.t.c.
Otherwise great video. 💙🚀
That was great thanks! We have been seeing inconsistencies with SwiftUI navigation in our Kotlin Multiplatform Application, which we finally solved using the Decompose library.
This is beautiful! Just the way I would use SwiftUI and UIKit together. I think SwiftUI navigation really sucks and this is a great way to have "imperative" navigation while also making it declarative and reactive using Combine. I also like how these coordinators not only abstract away the navigation, but also handle data flow and act in a way as a "view factory". Fantastic concept presented in the best way possible. Also I really like the example you showed in the video - it's both simple enough to not overwehlm the viewer and complex enough to show off the concept properly and also see the benefits of having unidirectional dataflow. Fantastic! Keep up the good work!
Thank you for a great tutorial!
MVVM is the same as MVC, just all the code from view controller goes in model view. It does not separate anything. MVVM replaces massive view controllers with massive view models. The only valuable thing Model View can do is to format model data. So it is good as two-way value transformers. But people just add complexity adding Combine, Coordinator and so on, that increases time for understanding such code.
Oh my gosh. Your video is brilliant. I like it a lot. I just started coding and after this video I am definitely clear with Coordinator pattern. By the way use SWIFTUI with UIKIT is a brilliant idea.Thank you very much for this content. Like and subscribe.❤
Thanks for this imformative tutorial! Keep up with the good work, please!!!! ❤️
I have noticed a few bugs (some show-stopping) with SwiftUI navigation that would be inconsistent between iOS versions on the app I am working on. I also had to go back to using UIKit behind the scenes for navigation. This is definitely a more elegant solution than what I am currently using.
Thanks for the info! Good to know I am not the only one
Nice tutorial on using coordinators, combine, and view models in UIKit with a bit of SwiftUI. Also I like the explanation of benefits of using Coordinator pattern (an ViewModels). I"ve used these patterns about three years ago in a commercial App (all UKit). What's your thoughts of using coordinators in a pure SwiftUI app (no UKIt)? Something I've just started to think about. Do you think the major issue is navigation?
I am not sure how to implement the Coordinator pattern with SwiftUI. It is designed for UIKit. I did a test on the navigation for SwiftUI ua-cam.com/video/vL0w3kvng0o/v-deo.html. I really like to simplicity and state driven navigation. One of my main issues with SwiftUI is the navigation because in this area I cannot find nice work arounds for bugs. Also not much customisation: is it strange to ask for a way to change the font of a navigation bar title? This is probably a very common task.
Thanks this was really useful.
yes, it is awesome video tutorial. Thank you for sharing your experiences.
Awesome video! There is only one thing that I don't really understand, why are we storing references to the child coordinators in the parent coordinator class ?
Thanks for the great video!
This was fantastic - thanks!
On the one hand this is a great way to get rid of the dependencies between views that NavigationLink creates by requiring an opaque type and get the navigation out of the VC...on the other hand it's going to huge pain in the ass if Swift projects are going to need UIKit navigation and SwiftUI views for the foreseeable future...
Nice video, I had to do something similar in my project, I like swiftUI a lot due to the speed up that it gives, but some bugs is very annoying, other than that I see a lot of performance issues with SwiftUI as well, my solution was to use UIKit for top level on everything, this also avoid some random redraws
Will there be a video on ELM architecture ?
Hey very helpful content as always 👌👌, can you please make a video on navigation between Swift Packages views using TCA.
Thanks!
Hello. I have a question about childCoordinators property. I've tried to comment all the lines with this variable and everything works as it should. Why do we need it? Other guides and articles also implement some methods to remove childCoordinators from parent's array when popping from them. Can you explain it somehow? Btw, thank you for the video!
I just have one question. How we will manage rest of Coordinator if we want to pass from FirstDetailView to OnotherView? Do we have to create ViewController again every section or we can continue just with NavigationStack?
Hi @karin Hope you are fine. Which one is better coordinator pattern or SwiftUi navigation which you showed in the last tutorial?
thank you for the video. deinit coordinator is too difficult, so i choose viper router to handle the navigation...
Thanks Karin for good content
Thanks. It was interesting to see a different method of achieving a clear separation of concerns in SwiftUI 👍 Combine ftw
Would you please consider using dark mode in the future? I'm watching these on a big screen, and light mode burns my eyes :D
This is a really interesting use of combine, but it seems like it would be much better to have the orientation flow as a modal under the navigation controller
I really like your approach. The only downside (and its pretty big) is you lose custom environment injection in SwiftUI (either custom environment keys, or environment objects). So I guess in your approach, you would hoist that data to a shared state singleton or thread it through the view hierarchy? I dont like either of those solutions, but I dislike SwiftUI navigation more : D
Sidenote: really great stuff on your channel. I'm getting a lot out of it, especially as a UIKit dev coming to SwiftUI.
Do you have a solution to this problem or think this can be solved by not ruining the concept of the Coordinator pattern?
Also @Karin I would love to hear your thoughts on this.
Great video and has really helped in my project.
thankyou, great tutorial
Glad you enjoyed it!
S tier content! :D
Can you put up a link or show your code on your navigation that causes that second draw/navigate at the beginning (right side)? The only time I ever see that is when I break the basics of state updates, usually because I've made a horrible mistake in timing or nav-time updates to state. I'm just not sure how you got that to be a thing.
Do you have tutorials for sales?
can someone please explain me how to transfer "hasSeenOnboarding" boolean state?
i don't understand one thing :
so in appCoordinator we create method which listen for the current state and depends on it load different flows: -
1.if user launch application for the first time it's goes up for "onboarding" flow...okay but how do actually we change the state of it while user end up looking for onboarding instructions?
I understand that Karin created observable object on appCoordinator, but which trigger change the state? She just pass this property inside " OnboardingCoordinator init() " And in start method simply put true inside this object.
where we add target or some action on done button of OnboardingView?
Thanks! I am just starting to learn Swift and this is incredibly useful.
Great to hear!
This might be a rare scenerio (and just a suggestion): can you add Objective-C view controller into this current structure, aka MVVM+C with SwiftUI View controller, UIKit View Controller, and Objective-C view controller? Some old project might be in the migration phrase and it does not tranalate its codebase to the Swift or SwiftUI fast enough.
I can't believe we're currently in SwiftUI 5 and NavigastionStack with NavigationPath is still problematic :|
good to see this comment, I just learned swiftui but havent done work with NavigationStack, Im aware of the problems it has cause ive been reading about it lol. Im gonna stick with UIKit for routing and SwiftUI for the rest
Great video Karin.. thank you for explaining the approach. Here instead of closers, isn't it better to just inject these coordinators inside the viewModels and then have those viewModels be injected in ViewControllers or Views. That way, from view or viewModel, we can directly call any methods on coordinators if need be,
No because you then cannot reuse the views as they have outside knowledge
at 6:25 you say the recommended pattern is MVVM and then go on to explain MVC
I guess better use Coordinators on Swift UI based
Valeu!
I can't believe more and more people don't reverse migrate back to UIKit. My time with swiftui was abysmal. I feel like it is still some time away from the standard for large projects
Those diagrams are so hard to understand…