What are the app states, and which callbacks fire as you move between them?
Predict first
A user presses the home indicator. Which state does the app reach first, and then eventually?
// A: Suspended, then Background
// B: Background, then Suspended after a short time
// C: Not running immediately- A
- B
- C
Mental model. A shop that is open and serving (active), open but with a customer holding up the queue (inactive), closed with staff finishing up (background), and closed with the lights off (suspended).
An app is always in one of five states. Not running: no process. Inactive: in the foreground but not receiving events (during a system alert, a call overlay, or at the very start of a transition). Active: in the foreground and receiving events: the normal state. Background: not visible but still executing code, usually only briefly. Suspended: in memory but executing nothing. The system can terminate a suspended app at any time to free memory, with no warning or callback.
Callbacks follow the transitions. On launch you get didFinishLaunching, then the app becomes active. Going to the home screen is will resign active, then did enter background; after a short time the app is suspended. Coming back is will enter foreground then did become active. In a scene-based app these UI events arrive on the scene delegate (sceneWillResignActive, sceneDidEnterBackground, …) while the app delegate keeps the process-level ones. Use resign active to pause work and enter background to save state and release resources.
It first enters the background, where it can run briefly, and is then suspended if it has no work that keeps it running.
| Visible | Runs your code | Can be killed silently | |
|---|---|---|---|
| Not running | no | no | – |
| Inactive | yes | yes, no events | only if memory is critical |
| Active | yes | yes | only if memory is critical |
| Background | no | briefly | yes |
| Suspended | no | no | yes, without notice |
Common traps
- Doing the saving in
willTerminate. A suspended app is killed with no callback, so save on entering the background. - Treating inactive as backgrounded. An incoming call or a Control Centre pull makes the app inactive, and it may become active again immediately.
They might follow up with
- When does
applicationWillTerminaterun? Rarely: only if the app is terminated while it is running, not for a suspended app. - How long do you have in the background? Only a few seconds unless you declare a task; the background-execution section covers it.
Related questions
- 6.2.2 What is a scene, and what is the split between AppDelegate and SceneDelegate?
- 6.2.5 What does state restoration restore, and how do you make an app survive being killed in the background?
- 6.5.1 An app goes to the background. What can it still do, and how do you choose a mechanism?
What is a scene, and what is the split between AppDelegate and… →