UIViewController lifecycle states: network vs geometry updates

What's really being asked

This question checks whether you understand the UIViewController state machine and can distinguish between view creation, visibility, and layout events. Interviewers want to see that you know which hooks are safe for expensive one-time work, which recur every time the view appears, and which fire when geometry changes.

The full answer

First, loadView, which only runs if the view property is nil and lets you build a view hierarchy programmatically. Second, viewDidLoad, called once after the view is created or loaded from a storyboard, ideal for one-time setup and initial network requests. Third, viewWillAppear and viewDidAppear, which run every time the view is added to the window hierarchy; viewWillAppear can trigger a refresh if data might be stale. Fourth, viewWillDisappear and viewDidDisappear, used to stop timers, save state, or end editing. Fifth, viewWillLayoutSubviews and viewDidLayoutSubviews, which fire when the view bounds change; viewDidLayoutSubviews is the correct place to read final bounds and update frames or layout-dependent layers after Auto Layout has finished. A strong candidate explicitly separates network work from layout work, placing requests in viewDidLoad or a coordinator rather than in layout methods.

The mistakes people make

A frequent mistake is initiating network requests inside viewDidLayoutSubviews, causing repeated fetches on rotation or split-view resize. Another is computing frames or reading bounds in viewDidLoad before the view has resolved its final size or safe area insets. Some candidates also claim all setup belongs in viewWillAppear, which wastes resources because that method runs every time a navigation controller pushes or pops back to the screen.

What usually comes next

The interviewer may ask where to register and unregister observers or notifications, which is typically viewWillAppear and viewDidDisappear. They may ask how traitCollectionDidChange or viewWillTransition fit into the lifecycle. They may also probe whether you understand the difference between viewDidLoad and init, or how to handle memory warnings via didReceiveMemoryWarning.

A concrete example

Consider a social feed profile screen. In viewDidLoad you create the table view, configure constraints, and start a network request to fetch the user model. In viewDidLayoutSubviews you read the final view bounds and update a custom avatar background gradient layer so its frame matches the header width exactly. You do not set that layer frame in viewDidLoad because safe area insets and final bounds are not guaranteed there, especially on devices with dynamic islands or when the view is embedded in a container.