Skip to content
Prepare to Grow
Open navigation

UIKit Development

Presentations, Alerts, and Child View Controllers

Present temporary tasks, request focused decisions, and compose controllers with correct containment lifecycles.

Intermediate5 min read2 guided activities

Before you begin

What you will understand

  • Choose push, sheet, full-screen, or alert by relationship.
  • Configure modern sheet presentations.
  • Use alerts for focused decisions.
  • Implement child-controller containment correctly.
01

Learning stage

Concept Explanation

Presentation style communicates product meaning. Push for hierarchy; present a sheet for a temporary task that preserves context; use full screen only when immersion or workflow demands it. On iPad, popovers require a source view or bar button item. The presenter must be in the visible hierarchy and should not present a second controller during an active transition.

UIAlertController is appropriate for brief information or a small decision. Routine field validation belongs inline. Destructive choices should use a destructive action style and clear consequences. A sheet presentation controller can provide detents, a grabber, and expansion behavior without custom gesture code.

Child containment composes controllers within one screen. Call addChild, place and constrain the child's view, then call didMove(toParent:). Removal reverses the lifecycle with willMove(toParent: nil), view removal, and removeFromParent. Containment is not merely adding another controller's view; the relationship forwards appearance, traits, rotation, and environment behavior.

  • Modal presentation: temporary flow layered over current context.
  • Detent: supported sheet height.
  • Alert action: focused response with semantic style.
  • Containment: parent-child controller relationship.
  • Appearance forwarding: child participation in lifecycle transitions.
02

Learning stage

Syntax & Examples

A reusable container embeds a child with the complete containment sequence.

DashboardViewController.swiftswift
func install(_ child: UIViewController, in container: UIView) {
  addChild(child)
  child.view.translatesAutoresizingMaskIntoConstraints = false
  container.addSubview(child.view)
  NSLayoutConstraint.activate([
    child.view.leadingAnchor.constraint(equalTo: container.leadingAnchor),
    child.view.trailingAnchor.constraint(equalTo: container.trailingAnchor),
    child.view.topAnchor.constraint(equalTo: container.topAnchor),
    child.view.bottomAnchor.constraint(equalTo: container.bottomAnchor)
  ])
  child.didMove(toParent: self)
}

func remove(_ child: UIViewController) {
  child.willMove(toParent: nil)
  child.view.removeFromSuperview()
  child.removeFromParent()
}
The parent establishes and removes both the controller relationship and the view hierarchy.
03

Learning stage

Real-World Usage

Connect the UIKit concept to complete, maintainable application features.

  • Present an editor as a resizable sheet.
  • Confirm permanent deletion with a destructive alert action.
  • Embed a child controller for a dashboard region.
  • Build custom containers for product-specific navigation.
04

Learning stage

Common Mistakes

Identify lifecycle, ownership, identity, layout, accessibility, and user-experience risks.

  • Using an alert for every validation message.
  • Presenting from a controller that is not visible.
  • Forgetting popover source configuration on iPad.
  • Adding a child view without addChild and didMove.
  • Using full-screen presentation for a lightweight contextual task.
05

Learning stage

Practice Exercises

Build the behavior in a small Xcode project and inspect it across realistic states.

Activity 1

Present an editor sheet

Present a navigation-wrapped editor with medium and large detents, Save and Cancel actions, and a clear dismissal contract.

Hint: The editor should report completion rather than reach into the presenting screen.

Activity 2

Swap child controllers

Create a container that transitions between loading, content, and error child controllers using correct containment calls.

Hint: Keep at most one active child and define the transition order.

06

Learning stage

Knowledge Check

Answer each question before revealing the explanation.

QUESTION 1

Which calls complete child-controller installation?

  1. A.addChild, add/constrain the view, then didMove
  2. B.Only addSubview
  3. C.present then dismiss
  4. D.push then pop
Reveal answer

addChild, add/constrain the view, then didMove

Both the controller hierarchy and the view hierarchy must be established.

QUESTION 2

When is an alert a good choice?

Reveal answer

For important brief information or a small decision that deserves interruption.

Routine guidance and field validation are clearer inline.

07

Learning stage

Interview Preparation

Explain the design in terms of lifecycle, identity, ownership, system behavior, and trade-offs.

How do you choose between navigation, modal presentation, and containment?

Short answer: Use hierarchy for deeper content, modal presentation for temporary tasks, and containment to compose controllers inside one screen.

Explore the detailed answer

The information relationship drives the choice. I also account for size-class behavior, dismissal, iPad popovers, and state restoration. Custom containment includes the documented parent-child lifecycle rather than only moving views.

Possible follow-ups

  • • What does didMove(toParent:) signal?
  • • When should a sheet use multiple detents?
08

Learning stage

Key Takeaways

Presentation and containment APIs express relationships between tasks and screens. Correct semantics and lifecycle calls preserve system behavior.

  • Choose presentation by product relationship.
  • Use alerts only for focused interruptions.
  • Configure adaptive popovers and sheets.
  • Containment requires controller and view hierarchy calls.
  • Give presented flows explicit completion and cancellation contracts.