How do AppDelegate and SceneDelegate responsibilities differ?
iOS 13 scene architecture mastery.
AppDelegate owns process events (launch, push); SceneDelegate owns per-window lifecycle and UI.
Putting all UI logic in AppDelegate or claiming SceneDelegate is optional.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
In an iOS 13+ app using scenes, which task is appropriately handled by SceneDelegate rather than AppDelegate?
- a.Setting up a process-wide Core Data container
- b.Handling a silent push notification to refresh shared data
- c.Restoring user interface state for a specific window sessionCorrect
- d.Configuring the app's dependency injection container at launch
Why? this is the answer
SceneDelegate owns per-window state restoration and UI lifecycle, whereas AppDelegate manages process-wide singletons and events. Option B is tempting because it occurs in the background, but silent pushes are process-level and must be handled by AppDelegate.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
- #ios
- #appdelegate
- #scenedelegate
- #uikit
- #lifecycle
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ios — each one lists the topics its interview covers.
See open roles