Navigation

Module 1 of 11 0%

Navigation in iOS applications refers to the system of moving users between different screens and content areas within your app. It’s essentially how users traverse your application’s interface, allowing them to access different features and content.

In iOS, navigation is more than just moving from one screen to another—it’s a core part of the user experience that:

Establishes a visual hierarchy of content
Provides context about where users are in your app
Creates a logical flow between related tasks and information
Helps users understand how to get back to previous screens
Maintains user state and data across different parts of the application

iOS provides several built-in navigation patterns and components that iOS users are familiar with, including:

Stack-based navigation: Using UINavigationController to push and pop view controllers
Modal presentations: Presenting view controllers modally for focused tasks
Tab-based navigation: Using UITabBarController to switch between major app sections
Page-based navigation: Swiping horizontally between related content
Container view controllers: Custom navigation patterns with container view controllers

Implementing a well-structured navigation system is crucial for several reasons:

1. Maintainability

Separation of concerns: Good navigation architecture separates navigation logic from view controller logic, making your codebase more modular
Reduced coupling: View controllers shouldn’t know about each other directly, reducing dependencies
Easier refactoring: When navigation logic is centralized, changing navigation flows doesn’t require modifying multiple view controllers
Scalability: As your app grows, proper navigation architecture makes it easier to add new screens without breaking existing flows

2. Code Reusability

Reuse view controllers: When view controllers don’t contain navigation logic, they can be more easily reused in different contexts
Shared transitions: Navigation patterns can be standardized across the app
Common navigation behaviors: Error handling, authentication flows, and other navigation behaviors can be implemented once and reused

3. Testability

Unit testing: Isolated navigation logic can be tested independently from UI
Mock navigation: Navigation dependencies can be mocked for testing view controllers
User flow validation: Complete user journeys can be tested more easily

4. User Experience Consistency

Predictable behavior: Users learn how navigation works in your app and expect consistency
Animation consistency: Standard transitions between screens create a polished experience
State preservation: Proper navigation architecture helps preserve app state during navigation
Accessibility: Well-implemented navigation systems work better with VoiceOver and other accessibility features

5. Adaptability to Platform Changes

Easier to adapt: When Apple introduces new navigation paradigms or components, a well-architected app is easier to update
Device compatibility: Navigation that works well across iPhone, iPad, and potentially Mac with Catalyst

1. Segues and Storyboards

Storyboards provide a visual way to design your app’s user interface and define the transitions (segues) between view controllers.

How It Works

You create view controllers in a storyboard and define their properties
You connect view controllers with segues to establish navigation paths
Segues can be triggered by user actions (like button taps) or programmatically

Types of Segues

Show (Push): Pushes a view controller onto a navigation stack
Present Modally: Presents a view controller modally
Present as Popover: Presents content in a popover
Custom: Define your own transition animations

Code Example

// Triggering a segue programmatically
@IBAction func buttonTapped(_ sender: UIButton) {
    performSegue(withIdentifier: "showDetailSegue", sender: self)
}

// Preparing for a segue
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    if segue.identifier == "showDetailSegue" {
        if let destinationVC = segue.destination as? DetailViewController {
            destinationVC.itemId = selectedItemId
        }
    }
}

Visual Representation

┌────────────────┐     showDetailSegue     ┌────────────────┐
│                │ ───────────────────────>│                │
│  MainScreen    │                         │  DetailScreen  │
│                │ <───────────────────────│                │
└────────────────┘                         └────────────────┘

Pros

✅ Visual design of navigation flows
✅ Quick to implement for simple apps
✅ No need to write code for basic transitions
✅ Preview of UI without running the app
✅ Interface Builder automates constraint setup

Cons

❌ Difficult to manage in team environments (merge conflicts)
❌ Limited flexibility for complex navigation scenarios
❌ Can lead to Massive View Controllers
❌ Segue identifiers are stringly-typed (prone to typos)
❌ Difficult to test programmatically
❌ View controllers become tightly coupled

Programmatic navigation involves writing code to explicitly push, present, or dismiss view controllers.

How It Works

Create and configure view controller instances in code
Use UINavigationController methods to push/pop or use present/dismiss directly
Handle view controller transitions manually

A UINavigationController is a fundamental container view controller in UIKit that manages a stack of view controllers in a navigation hierarchy. Here’s an explanation of what it is and why it’s used:

A UINavigationController is a container view controller that:

Manages a stack of view controllers - It maintains an ordered array of view controllers (the navigation stack)
Provides a navigation bar - The bar at the top of the screen shows the current view controller’s title and navigation controls (like back buttons)
Handles navigation transitions - It manages the animations and transitions when moving between screens in the stack
Maintains navigation history - It keeps track of the user’s path through your app’s interface

Code Example

// Push navigation example
func navigateToDetail(withId id: String) {
    let detailVC = DetailViewController()
    detailVC.itemId = id
    navigationController?.pushViewController(detailVC, animated: true)
}

// Modal presentation example
func presentSettings() {
    let settingsVC = SettingsViewController()
    settingsVC.delegate = self
    settingsVC.modalPresentationStyle = .formSheet
    present(settingsVC, animated: true, completion: nil)
}

// Dismissing a modal
@IBAction func dismissButtonTapped(_ sender: UIButton) {
    dismiss(animated: true, completion: nil)
}

// Popping from navigation stack
@IBAction func backButtonTapped(_ sender: UIButton) {
    navigationController?.popViewController(animated: true)
}

Visual Representation

Navigation Stack:

┌────────────────┐     push     ┌────────────────┐
│                │ ───────────> │                │
│  MainScreen    │              │  DetailScreen  │
│                │ <─────────── │                │
└────────────────┘     pop      └────────────────┘

Modal Presentation:

┌────────────────┐   present    ┌────────────────┐
│                │ ───────────> │                │
│  MainScreen    │              │  SettingsVC    │
│                │ <─────────── │                │
└────────────────┘   dismiss    └────────────────┘

Pros

✅ Complete control over the navigation flow
✅ Better for complex navigation requirements
✅ Easier to manage in source control (less merge conflicts)
✅ Better testability
✅ No string identifiers

Cons

❌ More code to write
❌ View controllers still know about each other
❌ Navigation logic mixed with view controller logic
❌ Less visual feedback during development
❌ Still can lead to tight coupling between screens

Tab-based navigation uses a UITabBarController to switch between distinct sections of your app.

How It Works

Create a UITabBarController as the root of your app
Configure multiple view controllers as tabs
Each tab can have its own navigation stack

Code Example

func setupTabBarController() {
    let tabBarController = UITabBarController()

    // Create first tab - Home with its navigation controller
    let homeVC = HomeViewController()
    homeVC.tabBarItem = UITabBarItem(
        title: "Home",
        image: UIImage(systemName: "house"),
        selectedImage: UIImage(systemName: "house.fill")
    )
    let homeNavController = UINavigationController(rootViewController: homeVC)

    // Create second tab - Profile with its navigation controller
    let profileVC = ProfileViewController()
    profileVC.tabBarItem = UITabBarItem(
        title: "Profile",
        image: UIImage(systemName: "person"),
        selectedImage: UIImage(systemName: "person.fill")
    )
    let profileNavController = UINavigationController(rootViewController: profileVC)

    // Set view controllers for tab bar controller
    tabBarController.viewControllers = [homeNavController, profileNavController]

    // Set as root view controller
    window?.rootViewController = tabBarController
}

Visual Representation

┌─────────────────────────┐
│   UITabBarController    │
└─────────────────────────┘
      /             \
     /               \
    /                 \
┌─────────────────┐      ┌─────────────────┐
│ Home Nav Stack  │      │ Profile Nav Stack│
└─────────────────┘      └─────────────────┘
|                       |
▼                       ▼
┌─────────────────┐      ┌─────────────────┐
│    HomeVC       │      │    ProfileVC    │
└─────────────────┘      └─────────────────┘
│
▼
┌─────────────────┐
│    DetailVC     │
└─────────────────┘

[   Home   |   Profile   ]  <- Tab Bar

Pros

✅ Easy access to key app sections
✅ Follows iOS design patterns that users understand
✅ Each tab can maintain its own navigation state
✅ Good for apps with distinct functional areas
✅ Built-in support in UIKit

Cons

❌ Limited to bottom-of-screen navigation
❌ Best practice limits tabs to 5 or fewer
❌ Not suitable for sequential or hierarchical workflows
❌ Can be challenging to navigate between tabs while preserving state
❌ Not suitable for all types of applications

4. Container View Controllers

Container view controllers manage and display content from other view controllers, allowing for custom navigation patterns.

How It Works

Create a custom container view controller
Add child view controllers to display their content
Manage transitions between children

Code Example

class ContainerViewController: UIViewController {
    private var currentViewController: UIViewController?

    func displayViewController(_ viewController: UIViewController) {
        // Remove current view controller if it exists
        if let currentVC = currentViewController {
            currentVC.willMove(toParent: nil)
            currentVC.view.removeFromSuperview()
            currentVC.removeFromParent()
        }

        // Add new view controller
        addChild(viewController)
        view.addSubview(viewController.view)

        // Configure view controller's view
        viewController.view.frame = view.bounds
        viewController.view.autoresizingMask = [.flexibleWidth, .flexibleHeight]

        // Complete the transition
        viewController.didMove(toParent: self)
        currentViewController = viewController
    }

    func transitionToViewController(_ viewController: UIViewController, duration: TimeInterval = 0.3) {
        // Start transition
        let previousVC = currentViewController
        addChild(viewController)

        // Set up new view for animation
        viewController.view.frame = view.bounds
        viewController.view.alpha = 0
        view.addSubview(viewController.view)

        // Animate transition
        UIView.animate(withDuration: duration, animations: {
            viewController.view.alpha = 1
            previousVC?.view.alpha = 0
        }, completion: { _ in
            // Clean up previous view controller
            previousVC?.willMove(toParent: nil)
            previousVC?.view.removeFromSuperview()
            previousVC?.removeFromParent()

            // Complete transition
            viewController.didMove(toParent: self)
            self.currentViewController = viewController
        })
    }
}

// Usage example
let containerVC = ContainerViewController()
let homeVC = HomeViewController()
containerVC.displayViewController(homeVC)

// Later transition to a different view controller
let detailVC = DetailViewController()
containerVC.transitionToViewController(detailVC)

Visual Representation

┌────────────────────────────────────┐
│  Container View Controller         │
│                                    │
│  ┌─────────────────────────────┐   │
│  │  Child View Controller      │   │
│  └─────────────────────────────┘   │
└────────────────────────────────────┘

Pros

✅ Complete control over transitions and animations
✅ Can create custom navigation patterns not possible with standard components
✅ Good for complex UI with dynamic content areas
✅ Can maintain multiple active view controllers
✅ Allows for unique and app-specific navigation experiences

Cons

❌ More complex to implement
❌ Requires careful memory management
❌ Need to handle view controller lifecycle events manually
❌ More prone to bugs if child controllers aren’t properly added/removed
❌ Can lead to more complex architecture without careful planning

The Coordinator Pattern in iOS

Origin and Purpose

The Coordinator pattern was introduced to the iOS community by Soroush Khanlou in his 2015 talk at NSSpain titled “Coordinators Redux.” The pattern addresses a fundamental challenge in iOS development: managing navigation and flow logic between view controllers.

The Purpose

Before Coordinators, iOS developers typically handled navigation in one of two ways:

View controllers managing their own navigation, creating and presenting other view controllers directly
Using storyboards and segues to define navigation paths visually

Both approaches had significant drawbacks, particularly as apps grew in complexity:

View controllers became bloated with navigation logic
Screens became tightly coupled, making reuse difficult
Navigation flows were hard to change without major refactoring
Testing navigation logic in isolation was nearly impossible

The core purpose of the Coordinator pattern is to extract navigation and flow logic out of view controllers into dedicated objects called Coordinators. These Coordinators are responsible for:

Creating and configuring view controllers
Determining when and how to transition between view controllers
Managing the flow of information between view controllers
Encapsulating a logical unit of the app’s functionality (like user onboarding or checkout flow)

By doing this, view controllers can focus solely on their primary responsibility: managing views and user interactions within a single screen.

Benefits of the Coordinator Pattern

1. Separation of Concerns

View controllers focus on view logic: They manage their UI components, handle user input, and display data, without worrying about app-level navigation
Coordinators focus on navigation logic: They handle the transitions between screens and the flow of the application
Clear single responsibility: Each component in the system has a well-defined role
Reduced cognitive load: Developers can reason about individual screens without understanding the entire flow

2. Improved Testability

Isolated view controllers: Can be tested in isolation without mocking complex navigation
Testable navigation logic: Coordinators can be tested separately to verify correct flow
Easily mocked dependencies: View controllers can be provided with mock coordinators during testing
Flow verification: Entire user journeys can be tested by asserting coordinator behavior

3. Enhanced Reusability

Decoupled view controllers: Can be reused in different contexts and flows
Modular flows: Entire user journeys can be packaged as reusable coordinator modules
Composable navigation: Coordinators can be combined and nested for complex flows
Adaptable to different entry points: Same screens can be used in different sequences

4. More Maintainable Codebase

Centralized navigation logic: Changes to app flow require modifications in one place
Easier to understand architecture: Clear separation between UI and navigation
Scalable approach: Works well for both small and complex applications
Future-proofing: Easier to adapt to new iOS navigation paradigms

Basic Implementation with Unsplash App Example

Let’s examine a real-world implementation of the Coordinator pattern using the Unsplash app example. This implementation demonstrates how coordinators manage different flows within the application.

UINavigationController in the Coordinator Pattern

In the Coordinator pattern, the UINavigationController is particularly important because:

Navigation Control - The coordinator needs direct access to a navigation controller to push and pop view controllers
Centralized Navigation Management - By injecting the navigation controller into the coordinator, we give the coordinator full control over navigation
Separation of Concerns - View controllers don’t need to know about the navigation controller; they just tell the coordinator what the user wants to do.