A brilliant video, such clarity! Whenever you import UIKit, Foundation is no longer required as UIKit already imports Foundation! You'd know this but others would learn from you :)

Dear Paul, thanks so much, this is one of the best material (for more advanced programmers interested in architecture, design patterns) you ever made. I am so grateful. I tried once to implement the coordinator pattern, but struggled due to the mutual dependencies. You made it completely clear to me in this video. You saved my day! Thanks god for making you a SWIFT lecturer. 👍🏻

I've been following your content on HWS for a long time now, You are the best Paul ! No competition REALLY , among the too many good iOS teachers I know you can easily stand out because of your true understanding of apple's frameworks and tools. You provide clear and COMPLETE content. I'm gonna tell all my friends about and tell them to subscribe ;)

Great Video Paul. Explained in easy way. I am new to iOS and looking forward to your live app session.

Wonderfully done. This solves a lot of horrendous amount of task just to navigate from one scene to another. Absolutely Brilliant... I love this.

A good overview for the Coordinator Design Pattern! Thumbs up!

This is the 1st video of you I watched... AWESOME ! Thanks a lot

An awesome explainer on coordinators! Thanks Paul

Thank you for this video! You just made it clear to me! Congrats!

Single storyboard file causes a lot of trouble when working in team. I would also create separate storyboard file for each view controller with the same name. It will help you with merge requests with less conflicts. Anyway, nice and clear tutorial 👌

Thank You So Much, Paul. 🤝👏👏👌 It's pretty clear and precise. Finally I Understood this pattern.

Great tutorial. Thanks for everything! Subscribed.

Such a good explanation. How about navigating back or popping view controllers and handling view controllers that are not pushed but presented?

I like that you are narrating most of the things you do in the video.

@Pual Hudson Such a perfect guide as always! But, how DRY is a code? You need to write all the methods inside MainCoordinator and repeat the same code in every method. Is there a way to avoid it?

Great tutorial!

Thank you a lot for this. It was a pleasure to watch.

Nice and clear explanation! I am guessing the view controllers should hold a reference to the Coordinator protocol but not the concrete MainCoordinator class?

Amazing Clarity of Concept. Thanks Paul. 1 question here, navController in MainCoordinator is visible to all viewcontrollers ?

Great class about Coordinators! Thanks!

I'm just starting out with iOS programming, and of course my first try is with XCode 11. Following video/text gives no compile runtime errors, but when you tap on on of the buttons, it enters the IBfunction but never executes the controller method. After some searching, it appears that you need to do something a bit different now. Instead of making code changes in AppDelegate, I had to put it in SceneDelegate on the scene function. my SceneDelagte now looks like this, and it is working! Thanks for a great tutorial and explanation! import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var coordinator: MainCoordinator! var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = (scene as? UIWindowScene) else { return } let appWindow = UIWindow(frame: windowScene.coordinateSpace.bounds) appWindow.windowScene = windowScene let navController = UINavigationController() coordinator = MainCoordinator(navigationController: navController) coordinator.start() appWindow.rootViewController = navController appWindow.makeKeyAndVisible() window = appWindow } . . .

Nice explanation of the concept. I have one comment regarding components coupling. Yes, applying coordinator you decouple one VC from the other, but you introduce VC+Coordinator coupling instead. As one of possible solution to resolve it we may use blocks like onButtonPressed: () -> Void , which we can inject into VC and do implementation of the block right inside of coordinator. What do you think? Found the answer in the end of next video...

This is awesome. So much to digest. Would be nice to be able to get the source code.

Great video, what about coordinators with multiple Storyboard?

Would it be possible to use this practice on programmatically created views/viewcontrollers? Say a dynamic pop-up view.. how does the coordinater handle constraints on dynamic views? how and where should the constraints be handled? Great video btw :-)

Thank you for that!

Great video Paul! It would be great to have a video on how to implement/when to use Child Coordinators. Right now when I do Coordinators I only have one. An example showing how to make a destroy children, and also showing how to use Coordinators to create different views on iPhone vs iPad would be super helpful!

awesome! It took me a while to get here but finally I got it.

What a brilliant video and I followed the videos instructions there was only one thing that doesn't work when I initialize each ViewController's Coordinator as a weak var functions of the coordinator doesn't get called and when I just remove the weak keyword from coordinator's initialization everything works great idk why and how and this happens in Xcode 11.5

Hi Paul! thank you so much for all the hard working you and your team are doing for us all those years! I'm an iOS developer and came across you tutorial here, and just wanted to NOTE something: When using Xcode 14.2, I managed to get this pattern design to work ONLY when implementing the code at 12:00min ('AppDelegate'->'DidFinishLaunching') at ('SceneDelegate'->'WillConnectTo' method) Here's my version of it: guard let windowScene = (scene as? UIWindowScene) else { return } let navigationController = UINavigationController() mainCoordinator = MainCoordinator(navigationController: navigationController) mainCoordinator?.configRootVC() window = UIWindow(windowScene: windowScene) window?.rootViewController = navigationController window?.makeKeyAndVisible() So, to anyone having trouble implementing this tutorial at 2023 - ENJOY! Thx again 😎

Could you please suggest me, how to build custom navigation bar with left and right bar items/buttons using coordinators? For eg. Once user does login and navigates to home screen, that is logout button as right navigation bar item. This will display in all the screens after login screen. How to handle such thing? That all logic goes somewhere in coordinator?

Simple, Great.

Helpful video. Thanks for making it. If you ever tire of Swift, you could work as an animator at Pixar. In that case, please make a WALL-E prequel. I would like to see how the apocalypse happened and how WALL-E experienced it.

Awesome video. But how to handle a custom transition presentation of a view controller.

You are great! Can you show coordinator for those who don't use storyboards?

Thank You!

wow, this is awesome

This is the whole chapter of your Patterns book)) I use this pattern now. Very useful. (btw I have 8 of your books)

Dear Paul. Can you recommend any links on how would the co-ordinator pattern be applicable to Swift UI?

If you are using Xcode 11 or newer and want to use the new SceneDelegate, you need to move the AppDelegate code to the SceneDelegate.scene method. After the guard clause, you create the navController, the coordinator, and set the rootViewController. I don't think you need the code to initialize the window because that's taken care of. guard let _ = (scene as? UIWindowScene) else { return } let navController = UINavigationController() // Don't forget to add var coordinator: MainCoordinator? to the top of the class coordinator = MainCoordinator(navigationController: navController) coordinator?.start() window?.rootViewController = navController window?.makeKeyAndVisible()

Where can I download the tutorial project?

great! big thx

Would be nice to see a parallel with SiftUI

Thanks for sharing. Do you use Viper pattern ? It will be great to see implementation of app with Viper.

You should put each storyboard in their own file so that other users on git can work on other classes while you work on your classes.

Amazing!

looks good Mr. Hudson

can you show more examples on where the child coordinators can be used, also an app where we have multiple coordinators?

I love this video. Thanks a lot. But can you show how to use coordinators with multiple storyboard?

I can recommend coordinators. Really nice video explaining it Paul, as always. I am wondering though, why would the Coordinator protocol describe having a UINavigationController? It should be up to the specific coordinators wether or not it presents things in a navigationcobtroller or something else like a tabbarcontroller or even something custom. The viewcontrollers also don’t need to know that, but with the protocol, they do. Am I missing something?

looks like I'm missing the childCoordinators variable being initialized. the project build fails since the initialization of the MainCoordinator is not full.

What if I want to present another NavigationController instead of push

nice video to explain mvvmc

I still think navigation is pretty easy the normal way. The main problem for me is deciding on a navigation stack or going modal. I think with a project greater than around 15,000 lines of code, I would look at a coordinator pattern. In other words if it's a simple app, I would go with the normal way of doing things.

Thanks for information. I just do not understand one thing, if we are using coordinators to break coupling than why do we couple each viewcontroller to exactly one coordinator? Does not this coupling breaks whole idea of coordinators, and making viewcontroller not reusable?

Super awesome!!! 😭

Is there any advantage in using storyboards for isolated view controllers over Xibs for each one? Great video as always, Paul!

Liking this 3 years after i watched it the first time

GOLD!

Great video.How to use this coordinator pattern for separate the delegates and datasources

Rama and shyam are playing football.is it simple or compound sentence,? Sr plz explain it

Awesome.

Thank god for saving me of using storyboards lol

Where do we use the childcoordinators array

I have one doubt here: UIViewController object have storyboard property initialized. Will it increase memory if we create new main storyboard instance everytime?

Someone just told me I might be somewhere here... Thanks for the shoutout! And I hope this joke will have a long life! 😁

How can you declare the coordinator in the ViewController as being 'weak'. When I do this, the compiler says'weak' must not be applied to non-class-bound 'Coordinator'; consider adding a protocol conformance that has a class bound. Did I miss something or is it because I'm using Swift 5 now.

hi @paul, i want to know how coordinator works if we want to add subview to current view controller ? subview can be like child view controller or view with date picker...can be anything...

Confused as to why this isn't working for me, i've copied the code bit by bit and whenever i click on the buttons nothing seems to happen. Strange

What if we need to use this pattern in multiple storyboard like if I have 2 storyboard how can I use this pattern there ?🤔

I am thinking: If all the 'Coordinator' is actually doing, is navigation. Why wouldn't we not use just an instance of UINavigationController as "Coordinator"? Even more, when every instance of UIViewController needs a 'var coordinator : Coordinator' while the property 'var navigationController' is already implemented by UIKit for free in every VC. The creation of new VC, as well as the navigation stuff would also be "outsourced' to the, well lets say, to the "MainCoordinatorNC" that inherits from UINavigationController. Bad idea?

Paul do you think it would be a good idea to mark the coordinator in VC's as Coordinator! instead of Coordinator? I mean, anyway without the coordinator the app will have no sense.

What is proper way move from Buy view controller to account view controller using coordinators? Buy view controller must be removed from stack?

I am trying to replicate this, but when I run it, I get a build fail "Type ViewController does not conform to protocol "Storyboarded" in ViewController.swift. I thought this was effectively disabled through removing Main. I think I have followed all your steps... can you help? Thank you.

I get a compile-time error: “Method ‘instantiate()’ in non-final class ‘ViewController’ must return ‘Self’ to conform to protocol ‘Storyboarded’. I checked, and the static func instantiate() does return Self, namely: return storyboard.instantiateViewController(withIdentifier: id) as! Self Is it because my Xcode only has Swift 4.0? The error points to the line: static func instantiate() -> Self {

I came up with a solution inspired by functional programming. My view controllers manage presenting the next view controller on their own, but which view controller they present is decided by a closure. All they know about is what data they can provide to the next view controller and possibly some labels for the data. For example, if you have a view controller that allows you to select three numbers using sliders and submits these numbers with an ok button, that one would take a closure of type (Float, Float, Float) -> UIViewController and some description what those sliders mean etc

Is anyone having an issue where the frame size of UIWindow is too small for any device? I've tried two different projects.

Can view controller delegate prepareForSegue in coordinator?

How would you use this with view controllers that need information to know what to display? E.g. a profile would need an ID. Just as parameters to the coordinator functions?

How should we complete the part at min 12:00 in Xcode 11 since the introduction of the Scene Delegate file? I tried to put the code as yours but it doesn't work. I tried to put that in Scene Delegate but it doesn't work. Thanks

15:53 is it violating Interface segregation principle ?

I don't get it why we need to set vc.coordinator = self. And what's the point of the childCoordinators?

Just wondering what if we also wanted to pass data between VCs. With Coordinator pattern, should coordinator code be made to take care of that too. How do we let VC know the coordinator telling "If you want me to push this to so and so VC, then you are also supposed to supply me with this and this data".

do you have an instagram or other kind of social media page?

MVC and Apples setups are pretty easy to understand and work well. Coordinators can easily become over engineered, and everyone creates an app that uses a different coordinator implementation, which you'll have to learn EVERY TIME! Yes, work in the industry long enough and you'll see that every app has a different Coordinator implementation that's just as different as you could imagine, without the supporting documentation (like you have with apples standards library).

This is so awesome and i can see the benefits...but for some reason i am still not getting it 100% :/ And I don't want to copy/paste the code and just use it without understanding how it is made from skratch. I guess i will put this video on repeat and try to figure out which pieces i am missing :) Great video!

Paul, giving all view controllers "weak var coordinator: MainCoordinator?" dependency is not a good thing...

Great video, subscribed. Curious how wasn’t subscribed yet ¯\_(ツ)_/¯ Already used coordinators for one of small projects after reading your post “How to use the coordinator pattern in iOS apps”. Now I’m thinking about slow migration to MVS+Cordinators for one of the projects with really huge VC classes. Could be interesting to hear opinion and expierience from others about risks and edge cases for slow migration. No way to rewrite everything in one release, there are more than 40 screens in that app.

Dude you rock, Imma pay ya a coffee in person one day. 5:13 7:39

Start here 3:33

What? Ofcourse you can reuse Segways... and the point is that you want it hard-coded so you have a clear flow. Sounds like coordinators are just another adventure in over-engineering. I've been using Coordinators in this pattern and if you have some interesting design, you'll run into all the same problems as and more when it comes to displaying content. In fact, it becomes more complex because the state of screens becomes lost as you move between views. I would only recommend coordinators for large enterprise applications without novel/unique design.

Storyboards and XIBs are not needed. We all shall use Code and Previews

Nice but keep em under 10 mins.