Outline the key steps and APIs for State Preservation and Restoration

What's really being asked

This tests whether you know UIKit's automatic state restoration machinery end-to-end, not just manual persistence patterns. Senior engineers should distinguish between system-driven preservation and ad-hoc archiving, and they should know the exact delegate methods and protocol methods involved.

The full answer

A good answer hits four things in order. First, the opt-in step: the app delegate must implement application:shouldSaveApplicationState and return YES, plus application:shouldRestoreApplicationState on launch. Without these, UIKit skips the entire pipeline. Second, the identifier chain: every view controller and container view controller in the target hierarchy must have a non-nil restorationIdentifier. UIKit uses these identifiers to encode the graph structure into a keyed archive, so if a navigation controller lacks one, the entire branch below it is lost. Third, the state encoding: each view controller should override encodeRestorableStateWithCoder to write transient properties like text field contents, scroll offsets, or selected segments, and override decodeRestorableStateWithCoder to read them back. Fourth, the lifecycle hook: the system calls application:willEncodeRestorableStateWithCoder at the start of preservation and application:didDecodeRestorableStateWithCoder after restoration, giving the app a chance to store global metadata. Strong candidates also mention viewControllerWithRestorationIdentifierPath:coder on the AppDelegate or view controller classes to handle custom instantiation when storyboards are not used.

The mistakes people make

Common wrong answers include describing a manual snapshot of the view hierarchy, using UserDefaults to stash view controller class names, or relying on applicationDidEnterBackground to do the work. Another red flag is forgetting that restorationIdentifiers must be set on every ancestor container, not just the leaf view controllers. Some candidates also confuse this with Scene State Restoration via NSUserActivity, which is a separate but related API.

What usually comes next

Interviewers often follow up by asking how you handle custom view controllers that cannot be instantiated from a storyboard, which is exactly what viewControllerWithRestorationIdentifierPath is for. They may also ask how you preserve the state of a custom view embedded in a view controller, which requires implementing UIStateRestoring on that view and attaching it via restorationIdentifier. Another common follow-up is how state restoration interacts with modern scene-based apps and multiple windows.

A concrete example

Imagine a tab bar controller with two tabs, each a navigation stack. To preserve this, you set restorationIdentifier on the UITabBarController, each UINavigationController, and every UIViewController in the stacks. In a detail view controller, you implement encodeRestorableStateWithCoder to write coder.encode(self.searchText, forKey: "searchText"), then in decodeRestorableStateWithCoder you read it back and apply it to the search bar. If the detail view controller is not in a storyboard, you implement viewControllerWithRestorationIdentifierPath in the app delegate, inspect the identifier path array, and return a freshly allocated instance configured with the provided coder.