How would you architect the app root for onboarding vs authenticated flows?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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.

ONE 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.