The Coordinator Pattern: Untangling iOS Navigation
The Coordinator pattern makes a separate object the 'boss' of app navigation, leaving view controllers to just manage their view. This lets you reuse views in different flows without them knowing what comes next.
Why it exists
In many iOS apps, view controllers become bloated with responsibilities, mixing view logic, business logic, and navigation flow. This creates 'Massive View Controllers' that are tightly coupled, hard to test, and nearly impossible to reuse. A view controller that knows how to create and present the next one cannot be easily repurposed in a different flow.
The mental model
Think of a coordinator as a film director and view controllers as actors. The director decides which actor comes on stage and when, but the actors don't direct each other. The coordinator is the single source of truth for application flow, while view controllers become simple, reusable objects focused only on presenting a view and binding data.
How it works
A top-level AppCoordinator, owned by the App Delegate, manages the main application flow. For specific tasks like a signup process, it spawns a child coordinator. The parent creates, starts, and holds a reference to the child. The child coordinator then creates and presents the first view controller in its sequence. Each view controller is configured with the coordinator as its delegate. When a user action requires navigation, the view controller notifies its delegate. The coordinator then decides what to do next, such as creating the next view controller in the flow. Once the flow is complete, the parent releases the child coordinator.
When to use it
Use this pattern to decouple view controllers and centralize navigation logic, especially in apps with complex flows or where views need to be reused. For example, if a profile screen can be pushed onto a navigation stack or presented modally, a coordinator can handle the presentation logic, leaving the ProfileViewController reusable and agnostic of its context. It also simplifies A/B testing user flows by just swapping coordinators.
When not to use it
For trivial, single-screen apps with no complex navigation, the pattern might introduce unnecessary boilerplate. However, as soon as an app has distinct user flows or requires reusing screens, the benefits of isolating navigation logic quickly outweigh the initial setup cost.
One canonical example
Consider a multi-step photo creation flow. The AppCoordinator would start a PhotoCreationCoordinator. This child coordinator would first present a photo picker view controller. After the user selects a photo, the picker informs the coordinator, which then dismisses the picker and presents a filter editor view controller. Each view controller is an 'island,' only communicating events back to the coordinator, which orchestrates the entire sequence.
Interview question
Which common problem in iOS app development does the Coordinator pattern primarily aim to solve?
- a.View controllers becoming tightly coupled and difficult to reuse due to managing navigation logic.Correct
- b.The challenge of unit testing view controller presentation logic without relying on UI.
- c.Difficulty in managing asynchronous data fetching and updates within view controllers.
- d.Memory leaks and strong reference cycles between view controllers causing app instability.
Why? this is the answer
The card explicitly states the pattern exists because 'view controllers become bloated with responsibilities, mixing view logic, business logic, and navigation flow. This creates 'Massive View Controllers' that are tightly coupled, hard to test, and nearly impossible to reuse.' Option A directly captures this core problem. While option B is a consequence of this coupling, it is not the primary problem itself.
Just read this? Test yourself on what you have been reading.
Read the original → khanlou.com
- #ios
- #swift
- #architecture
- #design pattern
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ios — each one lists the topics its interview covers.
See open roles