Coordinator: Key Concepts, Coordinator Pattern for iOS Navigation

What is Coordinator: The Essence of the Navigation Pattern

Coordinator is a pattern that takes responsibility for navigation in an iOS application. In standard UIKit, the ViewController itself manages transitions: present, push, show segue — all navigation methods are called from UIViewController. Coordinator extracts this logic: the ViewController reports an event (e.g., "the user clicked the login button"), the Coordinator decides which screen to show next. The ViewController is left only with UI logic and delegates navigation to the coordinator.

Pattern structure — CoordinatorProtocol with start() and finish() methods. start() — beginning of a flow: creating the first ViewController and displaying it. finish() — completing the flow with notification to the parent coordinator. Router — a wrapper around UINavigationController (or UISplitViewController), providing show, push, pop, dismiss methods. The coordinator does not work with UINavigationController directly — only through Router. This allows testing navigation and switching the UI framework.

Problems solved by Coordinator — Massive View Controller (navigation is a common cause of controller bloat). In standard UIKit, ViewController contains prepareForSegue, navigation delegates, unwind segue handling. Coordinator eliminates this. Storyboard segues are static connections between screens, Coordinator provides dynamic navigation with conditions. Testing navigation becomes possible: you can test Coordinator without UI by verifying the sequence of Router calls.

Coordinator in Swift: Implementation with Router and Flow

Basic Coordinator in Swift — a protocol with an associated type for Router and start/finish methods. Router — a protocol abstracting UINavigationController. A concrete Router implementation wraps UINavigationController and delegates methods to it. Coordinator accepts Router in init and uses it for navigation. Child coordinators are stored in the childCoordinators array for lifecycle management.

// Router — navigation abstraction
protocol RouterProtocol: AnyObject {
    func push(_ viewController: UIViewController, animated: Bool)
    func pop(animated: Bool)
    func present(_ viewController: UIViewController, animated: Bool)
    func dismiss(animated: Bool)
}

final class NavigationRouter: RouterProtocol {
    private let navigationController: UINavigationController

    init(navigationController: UINavigationController) {
        self.navigationController = navigationController
    }

    func push(_ vc: UIViewController, animated: Bool) {
        navigationController.pushViewController(vc, animated: animated)
    }

    func pop(animated: Bool) {
        navigationController.popViewController(animated: animated)
    }

    func present(_ vc: UIViewController, animated: Bool) {
        navigationController.present(vc, animated: animated)
    }

    func dismiss(animated: Bool) {
        navigationController.dismiss(animated: animated)
    }
}

// Coordinator — flow management
protocol CoordinatorProtocol: AnyObject {
    var childCoordinators: [CoordinatorProtocol] { get set }
    var router: RouterProtocol { get }
    func start()
    func finish()
}

class AuthCoordinator: CoordinatorProtocol {
    var childCoordinators: [CoordinatorProtocol] = []
    let router: RouterProtocol

    init(router: RouterProtocol) {
        self.router = router
    }

    func start() {
        let loginVC = LoginViewController()
        loginVC.onLogin = { [weak self] in
            self?.showHome()
        }
        router.push(loginVC, animated: true)
    }

    private func showHome() {
        let homeCoordinator = HomeCoordinator(router: router)
        childCoordinators.append(homeCoordinator)
        homeCoordinator.start()
    }

    func finish() {
        childCoordinators.removeAll()
        router.pop(animated: true)
    }
}

Creating Coordinator in AppDelegate/SceneDelegate — AppDelegate or SceneDelegate creates UINavigationController, wraps it in NavigationRouter, creates a root Coordinator (AppCoordinator) and calls start(). AppCoordinator decides whether to show onboarding, login, or the main screen — depending on the application state. Coordinator is the single entry point for navigation, ViewController does not know about other screens.

Child Coordinators and Coordinator Hierarchy

Coordinator hierarchy — AppCoordinator → AuthCoordinator/MainCoordinator → ProfileCoordinator/SettingsCoordinator. The child coordinator is created by the parent and stored in the childCoordinators array. When the child coordinator completes its work, it calls finish() on the parent, and the parent removes it from childCoordinators. This prevents memory leaks: Coordinator holds a strong reference to ViewController (through Router), and without removal from childCoordinators, the object will not be deallocated.

// Delegate for Coordinator -> Parent communication
protocol AuthCoordinatorDelegate: AnyObject {
    func authCoordinatorFinished(_ coordinator: AuthCoordinator)
}

class AuthCoordinator: CoordinatorProtocol {
    weak var delegate: AuthCoordinatorDelegate?

    func finish() {
        delegate?.authCoordinatorFinished(self)
    }
}

// AppCoordinator — parent
class AppCoordinator: AuthCoordinatorDelegate {
    func startAuthFlow() {
        let authCoordinator = AuthCoordinator(router: router)
        authCoordinator.delegate = self
        childCoordinators.append(authCoordinator)
        authCoordinator.start()
    }

    func authCoordinatorFinished(_ coordinator: AuthCoordinator) {
        childCoordinators.removeAll { $0 is AuthCoordinator }
        startMainFlow()
    }
}

Managing childCoordinators — dropping a Coordinator from the array is the only way to deallocate it. If you forget to remove a completed Coordinator, it stays in memory along with its ViewControllers. Recommended approaches: didMove(toParent:) of the parent, completion callback, or Combine publisher for automatic removal. The Coordinator pattern does not specify the notification mechanism — delegate, closure, or Combine — the choice is up to the developer.

Ways to Pass Data Between Coordinators

Passing data via delegate — the child Coordinator defines a delegate protocol with methods through which results are passed: func authCoordinator(_:didLoginWith user: User). The parent implements the protocol and receives data when the child flow completes. This is type-safe and explicit. Drawback: each child Coordinator requires a separate protocol. For projects with 10+ Coordinators, this leads to an increase in files.

Passing data via Result type — the finish method accepts Result, where Output is a generic type for the flow result. Coordinator

— a generic with an associated result type. start() with callback: start(completion: @escaping (Output) -> Void). This reduces code: no need to write a separate protocol for each coordinator. RxSwift/Combine: Coordinator publishes the result via PassthroughSubject/Publisher. The choice depends on the team's architectural approach.

Shared data layer — Coordinators do not pass data directly but use a shared service/repository. AuthCoordinator saves the token in Keychain/UserDefaults, ProfileCoordinator reads from there. Coordinators communicate through shared state (Dependency Injection container) rather than direct calls. This reduces coupling between Coordinators but creates implicit dependencies on shared state.

Comparison of Coordinator with Router, VIPER and MVVM-C

Coordinator vs Router — Router is a component of Coordinator that abstracts UINavigationController. Coordinator is responsible for the flow (which screen to show), Router — for the mechanics (how to show: push/present). Router is the "how", Coordinator is the "what". You can use Router without Coordinator (e.g., Navigator singleton), but Coordinator without Router is just a ViewController with a different abstraction. Usually both patterns are used together.

Coordinator vs VIPER — VIPER has a Wireframe component responsible for navigation — analogous to Coordinator. In VIPER, Wireframe is part of the module, Coordinator is a separate layer above modules. A VIPER module (View-Interactor-Presenter-Entity-Router) includes navigation as part of the module. Coordinator is external to modules: it creates and connects modules but is not part of them. Coordinator is more flexible for reusing screens in different flows.

MVVM-C — an extension of MVVM with Coordinator. ViewModel does not know about Coordinator directly — ViewController delegates navigation through ViewModel, ViewModel calls the coordinator through a protocol. MVVM-C is the standard approach for iOS projects with SwiftUI: Coordinator manages NavigationStack or fullScreenCover, ViewModel calls the coordinator by publishing state. Apple does not recommend Coordinator for SwiftUI — NavigationStack and NavigationPath are built-in navigation mechanisms.

// MVVM-C: ViewModel calls Coordinator through a protocol
protocol AuthNavigationProtocol: AnyObject {
    func showMainScreen()
    func showForgotPassword()
}

class AuthViewModel: ObservableObject {
    weak var navigation: AuthNavigationProtocol?

    func loginTapped() {
        // logic...
        navigation?.showMainScreen()
    }
}