Handle a deep link URL in SceneDelegate and navigate to order detail.
iOS scene-based deep links.
Handles willConnectTo and openURLContexts; parses path with URLComponents; validates ID; pushes detail onto nav stack.
Forgetting warm launches or routing without checking view hierarchy.
What's really being asked
This question tests whether you understand the modern iOS scene-based lifecycle for URL handling and can distinguish between cold-start and warm-launch deep-link entry points. Interviewers want to see that you know SceneDelegate is the correct starting point on iOS 13 and later, and that you recognize navigation requires a valid view hierarchy.
The full answer
First, state that there are two possible entry points. For a cold start, the URL arrives inside scene willConnectTo session options via connectionOptions.urlContexts. For a warm launch while the scene is already active, the system calls scene openURLContexts instead. Second, extract the UIOpenURLContext and pull out the URL. Third, use URLComponents to parse the path components rather than naive string splitting, so you safely extract orders and the identifier 451. Fourth, validate the identifier, for example ensuring it is numeric and non-empty. Fifth, access the root view controller, verify it is embedded in a UINavigationController or suitable container, and push or set the order detail view controller. If the app uses a coordinator or router pattern, mention delegating to that module.
The mistakes people make
A major red flag is only mentioning willConnectTo and completely forgetting openURLContexts, which means the deep link fails if the app is already running. Another is trying to handle the URL in the old AppDelegate application openURL method without scene awareness. Some candidates suggest parsing the URL with string separation by slash rather than URLComponents, which is brittle. Attempting to navigate before the root view controller hierarchy is ready, or force unwrapping view controllers, also signals a lack of production experience.
What usually comes next
The interviewer may ask how you would handle a universal link instead of a custom URL scheme, or how you would route the URL if the user is not logged in and must first pass through an authentication flow. They might also ask how to test this in the simulator, or how you would support iOS 12 and earlier where AppDelegate is still responsible.
A concrete example
Imagine the user taps myapp://orders/451 while the app is terminated. The system creates the UIWindowScene and calls scene willConnectTo session with connectionOptions. You iterate over connectionOptions.urlContexts, grab the first URL, create URLComponents from it, and read pathComponents. You check that pathComponents contains orders at index one and that pathComponents two is a valid integer. You then instantiate OrderDetailViewController with orderId 451, grab the root UINavigationController from the window, and call pushViewController animated true. If the app were already foregrounded, the same parsing logic would run inside scene openURLContexts.
Interview question
In a scene-based iOS app, which sequence correctly handles a deep link to an order detail for both cold and warm launches?
- a.Handle cold starts in willConnectTo and warm launches in openURLContexts; parse path components with URLComponents and validate the ID before pushing.Correct
- b.Route the URL via AppDelegate's application(_:open:options:) and broadcast a notification for SceneDelegate to push the detail view controller.
- c.Intercept every URL in openURLContexts because it fires for both cold starts and warm launches once the scene is connected.
- d.Handle all URLs in willConnectTo, extract the order ID by splitting the URL string, and force-unwrap the root view controller to push.
Why? this is the answer
Cold-start URLs arrive in willConnectTo through connectionOptions.urlContexts, while warm launches use openURLContexts, and URLComponents safely parses the path before validating the ID and pushing. The distractor that funnels everything through willConnectTo misses the warm-launch entry point, relies on brittle string splitting, and risks a crash by force-unwrapping the view hierarchy.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
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