How would you architect the app root for onboarding vs authenticated flows?
Tests window root swapping and state-driven architecture. Use a coordinator to own the window, swap rootViewController between nav and tab controllers on auth changes, and crossfade. Red flag: onboarding modal over tabs or keeping both hierarchies alive.
What's really being asked
This question evaluates whether you can separate authentication state from view controller hierarchy and manage the UIWindow rootViewController swap cleanly. Senior engineers should demonstrate they know how to avoid retain cycles, prevent jarring transitions, and keep the app delegate or scene delegate from becoming a massive controller.
The full answer
First, a dedicated app coordinator or root controller that owns the window and subscribes to auth state changes through a protocol or reactive publisher. Second, distinct container view controllers: a UINavigationController for the multi-screen onboarding flow and a UITabBarController for authenticated users, with no direct references between them. Third, swapping the window rootViewController based on state rather than presenting one over the other. Fourth, animating the swap with a snapshotView on the window or a CATransition to avoid a flash cut. Fifth, ensuring the outgoing hierarchy is fully released by niling strong references before the swap so memory does not grow on every login or logout.
The mistakes people make
A major red flag is making the onboarding flow a full-screen modal presentation over the UITabBarController, which couples the two flows and forces the tab bar to know about authentication. Another mistake is keeping both hierarchies in memory and hiding or showing layers, which wastes memory and complicates state restoration. Simply setting window rootViewController without animation is also weak because it degrades user experience. Finally, putting all the logic in the app delegate with no abstraction shows a lack of architectural separation.
What usually comes next
The interviewer may ask how you handle deep links that arrive while onboarding is active, or how you preserve the onboarding navigation stack if the app backgrounds and the session expires. They might also ask whether you would use child view controllers instead of swapping the root, or how you unit test the coordinator without instantiating the full UI. Another common follow-up is asking about state restoration and how you avoid re-showing onboarding after the user has already authenticated once.
A concrete example
Consider a fitness app. On cold launch, the scene delegate creates an AppCoordinator and injects an AuthService. The coordinator checks the keychain and finds no token, so it sets window rootViewController to a UINavigationController with a WelcomeViewController. The user taps Get Started, pushes through two onboarding screens, and logs in. The AuthService publishes a didAuthenticate event. The coordinator takes a snapshot of the current window, constructs a UITabBarController with Home, Workouts, and Profile tabs, sets it as the new rootViewController, and animates the snapshot alpha to zero over 0.25 seconds. The old UINavigationController and its stack deallocate because the coordinator only held it weakly or through a local variable. On logout, the process reverses.
Interview question
Which architecture best decouples auth state from the view hierarchy while ensuring smooth transitions and no memory leaks?
- a.Push the UITabBarController onto the onboarding UINavigationController stack after login and pop it on logout.
- b.Use an app coordinator to swap the window rootViewController on auth changes, crossfade with a snapshot, and nil the outgoing stack.Correct
- c.Keep both onboarding and authenticated container hierarchies in memory, toggling hidden state when the user logs in or out.
- d.Present onboarding as a full-screen modal over the main UITabBarController so the authenticated flow remains alive underneath.
Why? this is the answer
A dedicated coordinator that swaps the window root and releases the old hierarchy prevents retain cycles and keeps auth logic out of the app delegate. Presenting onboarding modally over the tab bar (D) tightly couples the two flows and forces the main interface to know about authentication state.
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