Difference between iOS state restoration VS User Defaults and SQLite?

Question

What I currently know:

• When an app is suspended, its memory space is not deallocated, but the app's code execution is paused. This means that any variables and objects that are currently in memory will still be there when the app resumes.

• However, if the app remains suspended for an extended period of time or if the system needs to free up memory for other apps, the operating system may choose to terminate the app to free up resources. When an app is terminated, all of its memory and data are released, and the next time the app is launched, it will start from scratch.

• If your app has implemented state preservation and restoration, any data that you've saved using the encodeRestorableState method will be available when the app resumes, even if the app was terminated in the meantime.

• If your app hasn't implemented state preservation and restoration, any data that wasn't saved before the app was suspended or terminated will be lost. It would be like starting from scratch on the home screen.

What I am confused about:

These statements imply that the main purpose of the state restoration methods is to preserve the state of an app "across" its lifecycle, specifically when an app has been terminated and removed from memory entirely. This is because if the app is only temporarily suspended and later resumed, any variables and objects currently in memory will still exist when we come back.

If that's true, what's the purpose of application(_:shouldRestoreSecureApplicationState:)? Do we really need it when we already have tools such as User Defaults and SQLite? Or is it simply a built-in layer on top of these existing tools?

Answer 1

The application state is different to the application data.

To use a word processor as an example:

The content of the document the user is working on is application data. The name of the document they are working on, and the font style they had selected are examples of application state.

Prior to iOS 4, there was no app suspension state; When the user pressed the home button, the active app was terminated and relaunched when they tapped the application icon.

App state preservation was important to give the impression that the app had actually kept running and not just drop the user back at the initial screen of the app after, say, they answered a phone call.

Although today it can take some time before an application is actually terminated, if your application has complex state that the user would expect to be maintained, then it is important to adopt state restoration. E.g. For a word processor, state restoration might be vital. For a social media app that always displays the most recent "feed", state restoration may not be important at all.

While you can use UserDefaults or even Core Data to store and retrieve application state, encodeRestorableState provides an elegant way for each UIViewController subclass to provide its state to the restoration process in isolation and without tightly coupling UIViewController classes to some state restoration object, which would happen if you used Core Data or UserDefaults.