Coordinator pattern in iOS Swift - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use the Coordinator pattern in iOS apps?

Which of the following best explains the main benefit of using the Coordinator pattern in an iOS app?

A It centralizes navigation logic to keep view controllers simple and focused on UI.

B It automatically generates UI layouts without coding.

C It replaces the need for storyboards entirely.

D It manages app data persistence across launches.

💡 Hint

Think about how navigation and screen transitions are handled in an app.

The Coordinator pattern helps by moving navigation code out of view controllers, making them easier to maintain and test.

❓ ui_behavior

intermediate

Coordinator navigation flow

Given a Coordinator that starts with a Login screen and then shows a Home screen after successful login, what happens when the user logs in?

iOS Swift

class AppCoordinator: Coordinator {
  func start() {
    showLogin()
  }
  func showLogin() {
    let loginVC = LoginViewController()
    loginVC.onLoginSuccess = { [weak self] in
      self?.showHome()
    }
    navigationController.pushViewController(loginVC, animated: true)
  }
  func showHome() {
    let homeVC = HomeViewController()
    navigationController.pushViewController(homeVC, animated: true)
  }
}

A The app replaces Login screen with Home screen without animation.

B The app pushes Login screen, then pushes Home screen on login success.

C The app shows Login and Home screens side by side.

D The app pops Login screen and then pushes Home screen.

💡 Hint

Look at how navigationController is used to push view controllers.

The code pushes Login screen first. When login succeeds, it pushes Home screen on top, so user sees Home next.

❓ lifecycle

advanced

Coordinator memory management

What is the main reason to use [weak self] in closures inside a Coordinator?

iOS Swift

loginVC.onLoginSuccess = { [weak self] in
  self?.showHome()
}

A To prevent a strong reference cycle that causes memory leaks.

B To make the closure run on a background thread.

C To ensure the closure runs only once.

D To allow the closure to modify self even if it is nil.

💡 Hint

Think about what happens if self holds a strong reference to the closure and vice versa.

Using [weak self] avoids retain cycles between the Coordinator and closures, preventing memory leaks.

❓ navigation

advanced

Handling child coordinators

In a Coordinator pattern, why do we keep a strong reference to child coordinators?

A To allow child coordinators to access the parent view controller directly.

B To enable child coordinators to modify the app delegate.

C To keep child coordinators alive while they manage their flows and prevent them from being deallocated.

D To automatically save child coordinator state to disk.

💡 Hint

Think about what happens if a child coordinator is not strongly referenced.

Without a strong reference, child coordinators get deallocated immediately, breaking navigation flow.

📝 Syntax

expert

Correct Coordinator protocol definition

Which option correctly defines a Coordinator protocol with a start() method and a navigationController property?

A

protocol Coordinator {
  var navigationController: UINavigationController? { get }
  func start() -> Void
}

B

protocol Coordinator {
  var navigationController: UINavigationController? { get set }
  func start() -> Int
}

C

protocol Coordinator {
  var navigationController: UINavigationController { get set }
  func start()
}

D

protocol Coordinator {
  var navigationController: UINavigationController { get }
  func start()
}

💡 Hint

The navigationController should be readable but not necessarily writable. start() returns nothing.

Option D correctly declares a read-only navigationController and a start method with no return value.