Describe the iOS app lifecycle and SceneDelegate methods

WHAT THIS TESTS This confirms you understand when your code runs as the system moves an app between states, and that since iOS 13 per-window scene callbacks handle UI lifecycle while the AppDelegate handles process-level events. It matters for correct save, pause, and resume behavior.

A GOOD ANSWER COVERS The states are not running, before launch or after termination; inactive, in the foreground but not receiving events, for example during a transition or incoming call; active, in the foreground and receiving events; background, executing code while not visible, often briefly before suspension; and suspended, in memory but not executing, where the system may kill the app under pressure. In a scene-based app the UISceneDelegate receives scene(_:willConnectTo:options:) to configure the window, sceneDidBecomeActive when it starts receiving events, sceneWillResignActive when it is about to stop, sceneDidEnterBackground when it leaves the screen, and sceneWillEnterForeground when returning. The AppDelegate still handles application(_:didFinishLaunchingWithOptions:) and scene-session configuration.

COMMON WRONG ANSWERS Describing only the old AppDelegate methods like applicationDidEnterBackground while ignoring scenes. Claiming suspended apps still run code. Saving important user data only at termination, which is never guaranteed to be called.

LIKELY FOLLOW-UPS Why did Apple introduce scenes? Where should you persist state, and why in sceneDidEnterBackground rather than at termination? How do multiple windows on iPad map to scenes? Is applicationWillTerminate reliable?

ONE CONCRETE EXAMPLE A note-taking app saves the draft in sceneDidEnterBackground because the user may swipe the app away while suspended, when no termination callback fires. When the user returns, sceneWillEnterForeground refreshes data and sceneDidBecomeActive resumes timers and analytics, giving a clean pause-and-resume cycle tied to the visible scene rather than the process.