What is jetsam, and how does it differ from a crash?
Predict first
Which apps does jetsam terminate first under memory pressure?
// A: the foreground app
// B: suspended apps
// C: apps with the most disk usage- A
- B
- C
Mental model. A bouncer clearing a packed bar: the people who are not doing anything (suspended apps) go first, and someone who takes up too much room can be asked to leave at any time.
Jetsam is the kernel’s memory-pressure killer. When free memory drops, it terminates processes in priority order: suspended apps first (they run nothing and are the cheapest to lose), then background apps, and the foreground app last. There is also a per-process footprint limit: an app that exceeds its limit is killed even when the system as a whole has memory to spare, which is how a single memory-hungry app, or an extension with a tiny limit, gets terminated. Footprint is dirty plus compressed memory, as described in the memory section.
It is not a crash. There is no signal, no exception and no stack trace in your app, and no callback to your code: the process simply ends. You find it in the device’s analytics data as a JetsamEvent report, and in MetricKit and Xcode Organizer under terminations. The user sees the app “restart from scratch” after returning to it. Two lessons follow. Because suspended apps are killed first, state restoration and saving on entering the background matter. And because it is footprint that counts, you fix it by lowering peak and resident memory, not by adding error handling.
Suspended apps cost the user nothing to lose, so they go first, then background apps, and the foreground app last.
| Cause | A callback to your code? | Where you see it | |
|---|---|---|---|
| Crash (exception or signal) | your code or a framework fails | sometimes (crash reporters) | crash report with a stack trace |
| Jetsam | memory pressure or footprint limit | no | jetsam event, MetricKit, Organizer |
| Watchdog | unresponsive launch, resume or task end | no | crash-style report, code 0x8badf00d |
| Background time expired | a task did not end in time | the expiration handler, once | termination report |
| User force-quit | the user swiped the app away | no | no report |
Common traps
- Searching the crash logs for a jetsam kill. It is not a crash. Look at jetsam events and termination reports.
- Assuming a background app is safe once it is “suspended”. Suspended apps are the first to go.
They might follow up with
- Why can an app extension be killed so readily? Its memory limit is much lower than an app’s, so a modest allocation can exceed it.
- How does it differ from the memory warning? The warning is advisory and comes first when it comes at all; jetsam is the action that follows.
Related questions
- 6.6.1 What should an app do on a memory warning, and how reliable is the warning?
- 6.2.5 What does state restoration restore, and how do you make an app survive being killed in the background?
- 3.7.5 What is memory footprint, and what gets an iOS app killed?
← What should an app do on a memory warning, and how reliable is the… What is the watchdog, and what causes the 0x8badf00d exception? →