How does the Coordinator pattern decouple navigation, and what are its components?
This tests iOS separation of concerns. Explain that Coordinators extract navigation logic from view controllers for reuse, and describe AppCoordinator tree with child coordinators. A red flag is treating it as a router or ignoring parent-child retention.
What's really being asked
This question probes your ability to recognize and fix architectural coupling in UIKit. Interviewers want to see that you understand view controllers are view objects prefixed with UI and should not own flow logic, and that you can articulate how a higher-level object can marshal view controllers without creating a massive central router.
The full answer
First, the motivation: view controllers often entangle flow logic, view logic, and business logic, which prevents reuse in extensions, iPads, or A/B tests. Second, the solution: a Coordinator is a plain old NSObject that takes over navigation and flow decisions, so each view controller becomes an island that only binds a model to a view. Third, the structure: an AppCoordinator lives in the app delegate and owns an array of child coordinators; each child might manage a navigation controller or a specific flow like authentication or photo creation. Fourth, memory management: coordinators are retained in a parent array and must be removed when a flow completes to avoid leaks.
The mistakes people make
Calling the Coordinator a router or a replacement for the navigation controller misses the point; it is an object that decides what comes next, not one that merely pushes view controllers. Another red flag is suggesting a singleton coordinator or a single global instance, which destroys modularity. Failing to mention the child coordinator array and the parent-child tree shows you have not thought through retain cycles or deallocation. Finally, saying view controllers communicate back via delegates is correct, but omitting that the coordinator implements those delegates to decide the next step is incomplete.
What usually comes next
How do you handle deep linking or state restoration with coordinators? How would you adapt this pattern to SwiftUI? What happens when a coordinator needs to pass data back up the tree? How do you prevent retain cycles between the coordinator and the view controllers it presents? Can you mix coordinators with MVVM or Clean Architecture?
A concrete example
Imagine an Instagram-style photo creation flow. The AppCoordinator has a root view controller and an array of child coordinators. When the user taps Create, the AppCoordinator allocates a PhotoCreationCoordinator, adds it to the childCoordinators array, and calls beginPhotoCreationProcess. That coordinator creates a photo selection view controller, sets itself as the delegate, and presents it. When the user finishes or cancels, the PhotoCreationCoordinator informs its delegate, the AppCoordinator, which removes it from the childCoordinators array. None of the view controllers in that flow know about each other, and the flow logic lives in one place.
Interview question
In a Coordinator hierarchy, why does the AppCoordinator typically store active child coordinators in an array?
- a.To keep flow coordinators alive during their lifecycle and allow parent-controlled cleanup when flows completeCorrect
- b.To enable view controllers to look up the next screen without holding a reference to the coordinator
- c.To provide a singleton registry where any object can access the current navigation state globally
- d.To replace UINavigationController with a custom stack that manages all push and pop transitions
Why? this is the answer
The parent array retains each child coordinator for the duration of its flow and enables cleanup on completion, preventing memory leaks. Option D is tempting but wrong because coordinators decide flow logic; they do not replace UINavigationController or handle transitions directly.
Just read this? Test yourself on what you have been reading.
Read the original → khanlou.com
- #ios
- #swift
- #coordinator
- #architecture
- #uikit
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