What is memory footprint, and what gets an iOS app killed?
Predict first
A 4000 × 3000 photo is 2 MB on disk. Roughly how much memory does the decoded bitmap use?
// A: about 2 MB
// B: about 12 MB
// C: about 48 MB- A
- B
- C
Mental model. iOS is a flat with no storage unit. If you pile things up, the landlord removes a whole tenant instead of renting you more space.
iOS has no swap file. When memory runs short the system terminates processes (jetsam), using each process’s footprint: roughly its dirty pages (memory your code has written) plus its compressed pages. Clean pages, such as memory-mapped files that can be re-read from disk, are cheap because the system can drop them. The limit depends on the device, the app type, and whether it is in the foreground; app extensions have much lower limits than apps.
You are not guaranteed a warning: a memory-warning callback often arrives first, but a spike can kill you without one. Watch footprint with the Xcode memory gauge or the phys_footprint value, check headroom with os_proc_available_memory(), and free caches in response to warnings. The most common surprise is images: a decoded bitmap costs width × height × 4 bytes, whatever the file size, so a 4000 × 3000 photo that is a few megabytes on disk is about 48 MB in memory. Downsample when you decode, not after.
4000 × 3000 pixels × 4 bytes per pixel is 48,000,000 bytes, independent of how well the file compresses.
Common traps
- Judging memory by file size. Decoded images dwarf their compressed files.
- Relying on
didReceiveMemoryWarningto save you. It is a courtesy, not a guarantee.
They might follow up with
- How do you decode a big image cheaply? Use ImageIO to create a thumbnail at the display size, so the full bitmap is never built.
- Why are extensions limited so tightly? They run alongside other apps with only a small budget, and are killed first.