How do AppDelegate and SceneDelegate responsibilities differ?

WHAT THIS TESTS: This question evaluates whether you understand the architectural split Apple introduced in iOS 13 between the app process and individual UI windows. Before scenes, AppDelegate managed everything. Modern apps use a scene manifest, so the interviewer wants to see that you know which object owns process-wide state versus per-window lifecycle events. It also reveals whether you have actually built multi-window iPad or macOS apps, or if you are still treating AppDelegate as the universal junk drawer.

A GOOD ANSWER COVERS: First, AppDelegate owns the single process lifecycle. This includes didFinishLaunchingWithOptions, registering for remote notifications, handling background fetch, and setting up process-wide singletons like Core Data or dependency injection containers. Second, SceneDelegate owns the lifecycle of individual UI instances. It handles sceneWillEnterForeground, sceneDidBecomeActive, sceneWillResignActive, and sceneDidEnterBackground. Third, AppDelegate still creates scene configurations via configurationForConnecting but should not manage view controllers inside that method. Fourth, process-wide events like silent push notifications or app termination belong in AppDelegate, while window-specific state restoration and user interface setup belong in SceneDelegate. Fifth, on iPad and macOS multiple scenes can run simultaneously, so SceneDelegate must be written to handle independent state.

COMMON WRONG ANSWERS: Putting all UI lifecycle and root view controller setup in AppDelegate as if scenes do not exist. Using SceneDelegate for process-level background tasks or push notification handling. Claiming AppDelegate is deprecated or that SceneDelegate is optional in modern apps; if the Info plist includes the scene manifest, SceneDelegate is mandatory. Failing to mention that multiple scenes can exist at the same time on iPad. Describing state restoration without noting that each scene has its own restoration activity.

LIKELY FOLLOW-UPS: How would you handle state restoration when a user has three document windows open on iPad? What happens to a background download when a scene disconnects but the app process stays alive? How do you route a universal link to the correct existing scene instead of creating a new one? Have you implemented handoff or drag and drop between scenes?

ONE CONCRETE EXAMPLE: Imagine a document editing app on iPad. When the user opens two documents in Split View, there are two UIScene instances, each with its own SceneDelegate. Toggling one window between light and dark mode triggers scene delegate methods for that scene only. Receiving a silent push notification to refresh shared templates triggers AppDelegate once for the entire process. If the user opens a document from the Files app, the AppDelegate receives the open URL context but must pass it to the appropriate scene session for routing.