Basics of States in the Lifecycle of an iOS App
As a matter of course, an app written in the iOS system goes through a set of states as it runs. These states are known as states of the app’s lifecycle. As an app moves through the states of its lifecycle, the state of the app is defined by its level of activity such as Not Running, Active or Suspended.
Here’s more information about the states:
When an app is in the Not Running state, either the app hasn’t been launched or the system shut it down.
When an app starts, it transitions through a short state, called the Inactive state. It’s actually running, but it’s performing other functions and isn’t ready to accept user input or events.
An app in an Active state is running in the foreground and receiving events. This is the normal mode for foreground apps — apps that don’t have to run in the background without a user interface.
When an app is in the Background state, its user interface isn’t visible, but it is running. Most apps transition through this state on their way to being suspended.
An app may need (and request) extra execution time and may stay in this state for a time. In addition, certain apps run in the background. Such an app enters the Background state directly and doesn’t go through the Inactive state.
The iOS system may move an app to a Suspended state. Here the app is in the background but is not running code. It does stay in memory, though. If a low-memory condition occurs, the system may purge apps in the suspended state without notice. Note that, according to Apple’s standards, only the iOS system can kill an app.
As your app goes through the states of its lifecycle, certain standard methods of the app, known as lifecycle methods are called by iOS. As it goes through these states, you can add app-specific behavior at each transition within the app’s lifecycle.
The reliability implications of this lifecycle are that whenever the app transitions from being active in the foreground to being in the background, to being suspended and then terminated, it has to
Give up all resources it’s holding (such as network connections and file pointers).
Save any state it wants to preserve when it’s restored to active duty or starts up again (this process is also known as checkpointing).
But giving up resources and saving state as the app exits is only half the story. As the app goes through its startup sequence and runs through its functions (in concrete terms, loads and exits each view controller), it should register what it needs to give up and what state it needs to preserve so that the resources are released and the state is saved if the app exits.