Architecting iOS apps: Coordinators

When switching from Windows Phone development to iOS I had about 3 months to learn iOS and Swift before starting the work on an actual iOS application. I had a chance to build the application from scratch with a colleague so I wanted the application to be really well written and architected. I started to look at some iOS tutorials and other peoples’ iOS code. Learning and using Swift was easy (read more about my Swift experience in a separate blog post) but when reading about using the iOS SDK and especially application architecture I found stuff that I really disliked. There were three big things in particular that I disliked, that I want to show you together with solutions I found. This first post deals with navigation. The problem When going through some iOS tutorials I found code like this a lot class ProfileViewController: UIViewController { @objc func donection(sender: UIButton) { let vc = PreferencesViewController() navigationController?.pushViewController(vc, animated: true) } } When you are a long-time iOS developer, you may have seen and probably written code like this. All the tutorials contain code likes this. It may look perfectly OK to you. But for me, coming from the .NET world, this was a real WTF moment: Why would anyone write code like this? Why the strong coupling between those two view controllers? Why an assumption the view controller is embedded in a navigation controller and we always want to do a push? This code looked absolutely awful to me and I never wanted to write a code like this. So I started looking for better approaches and solutions. And I found coordinators (sometimes called flow controllers). The solution: Coordinators The idea of a coordinator is simple. In your application you probably have some flows, like registration flow, user settings flow, product purchasing flow, etc. Every flow is managed by a coordinator. The role of the coordinator is to know which view controller to display at a certain time.