Push vs Modal Presentation in UIKit

WHAT THIS TESTS This checks whether you understand the mental model behind UIKit navigation and can choose the right presentation style for a given UX, which signals real app-building experience.

A GOOD ANSWER COVERS Pushing relies on a UINavigationController managing a stack. pushViewController places a new controller on top, the navigation bar shows a back button, and the transition slides horizontally, communicating that the user is drilling deeper into related, hierarchical content. Presenting modally with present(_:animated:) shows a controller that is not part of any navigation stack; by default it slides up and covers the screen. It signals an interruption, a focused task the user must finish or dismiss before returning. Modals own their own lifecycle and are dismissed with dismiss(animated:).

COMMON WRONG ANSWERS Claiming you can push without a navigation controller. Saying both are equivalent. Forgetting that modal presentation styles changed in iOS 13, where the default became a card that can be swiped down, which affects whether viewWillAppear fires on the presenter.

LIKELY FOLLOW-UPS How do you pass data and get a result back from each? How does the iOS 13 sheet presentation affect lifecycle callbacks? What is modalPresentationStyle and when would you use fullScreen versus pageSheet? How do navigation and modal map onto SwiftUI's NavigationStack and sheet?

ONE CONCRETE EXAMPLE In a messaging app, tapping a conversation pushes the chat detail onto the navigation stack, so the user can tap back to return to the list, reinforcing the hierarchy. Tapping a compose button presents a new-message controller modally, because composing is a self-contained task the user either sends or cancels, after which they land back exactly where they were.