UIKit

viewDidLoad runs exactly once per instance, right after the view hierarchy is created. viewWillAppear runs every time the view is about to go on screen — including when you come back from a screen you pushed.

So the split is one-time construction versus repeated refresh. Adding subviews, activating constraints, setting fonts and colours, wiring up targets: all viewDidLoad, because doing it again would duplicate work and can duplicate subviews. Anything that could have changed while the screen was away goes in viewWillAppear — re-reading a model, updating a badge, restoring navigation bar state, reflecting a setting the user changed two screens deep.

The bug you get from mixing them up is very recognisable: put a data refresh in viewDidLoad and everything looks right on first launch, then the user edits something on a detail screen, comes back, and the list still shows the old value.

For work that should start only once the transition is actually finished — animations, screen-view analytics, becoming first responder — I'd use viewDidAppear, since the view is genuinely on screen by then.

Two passes, in opposite directions.

First, hit testing, going down. UIKit calls hitTest(_:with:) on the window, which asks point(inside:with:) and then recurses into subviews back-to-front, returning the deepest view that contains the point. Views that are hidden, have user interaction disabled, or have alpha at or below 0.01 are skipped entirely. The result is the view the touch is delivered to.

Then the responder chain, going up. If that view doesn't handle the event, it goes to its next responder — normally the superview, then the view controller at the top of its hierarchy, then the parent or presenting controller, then the window, the application, and finally the app delegate. The first responder that implements the action handles it and the walk stops. If nobody does, the event is silently discarded.

For a target-action button with an explicit target, the walk is skipped — it goes straight there. The chain matters when the target is nil, which is how the system edit menu and the keyboard-dismissal trick work without knowing which field is focused.

The bug this explains most often is a button outside its parent's bounds: it's visible because the parent doesn't clip, but untappable because hit testing rejected the point at the parent before it ever looked at the button.