When an iOS app goes to the background, the system takes a screenshot of its current screen to show as the thumbnail in the app switcher. It is a nice touch for usability, but it is also a data-leakage risk you might not think about: whatever is on screen at that moment, an account balance, a private message, a document, gets captured and stored on the device. Anyone who opens the app switcher sees it, and the saved image sits in the file system. The fix is to hide sensitive content the instant the app backgrounds, before the snapshot is taken. Here is what the leak is and how to prevent it.
Short answer
When an iOS app moves to the background, the system captures a snapshot of its current screen for the app switcher and stores that image on the device. Per OWASP's mobile testing guidance, if sensitive data is on screen at that moment, account details, messages, personal information, it is captured into the snapshot, visible in the app switcher and saved in the file system, which is a data leak. The fix is to obscure sensitive content before the app backgrounds: in the lifecycle callback for resigning active or entering the background, cover the screen with a blank or branded overlay, or hide the sensitive views, then remove it when the app becomes active again. The snapshot then captures the overlay, not the sensitive screen.
What you should know
- iOS snapshots the screen on backgrounding: for the app switcher thumbnail.
- The snapshot is stored on the device: not just shown transiently.
- Sensitive on-screen data is captured: whatever is visible at that moment.
- Obscure before backgrounding: hide content in the lifecycle callback.
- Remove the overlay on returning: restore the screen when active again.
What is the snapshot leak?
It is sensitive on-screen content being captured into the app switcher snapshot. To make the app switcher show a live-looking thumbnail of each app, iOS takes a screenshot of an app's interface as it transitions to the background, and saves that image so it can be displayed later. The image reflects exactly what was on screen at the moment of backgrounding, so if the user was viewing something sensitive, their balance, a private conversation, a confidential document, that content is what gets captured. The leak has two parts: the thumbnail is visible to anyone who opens the app switcher on that device, and the saved snapshot persists in the file system, where it could be recovered from a compromised or backed-up device. It is a classic mobile data-leakage issue precisely because it is automatic and invisible: the developer did nothing to save the screen, the system did it, which is why it is easy to overlook.
When does it matter, and what leaks?
It matters whenever a sensitive screen can be on display at backgrounding. The table summarizes.
| Factor | Detail |
|---|---|
| Trigger | App moves to background while a sensitive screen is visible |
| What is captured | The full current screen, as an image |
| Where it goes | App switcher thumbnail and stored snapshot file |
| Who can see it | Anyone with the device open to the app switcher |
| Residual risk | The saved image persists on disk |
The exposure depends on what your app shows: an app that only ever displays non-sensitive screens has little to worry about, but any app that can have account information, personal data, financial figures, health details, or private messages on screen when the user switches away is at risk, because that is what the snapshot will contain. The two distinct concerns are immediate, someone glancing at the device sees the sensitive thumbnail in the app switcher, and residual, the image is written to storage and lingers, so it joins the data-at-rest surface. Both are addressed the same way: do not let sensitive content be on screen when the snapshot is taken.
How do you prevent it?
Obscure the screen before the snapshot, then restore it. iOS gives you lifecycle callbacks as the app transitions away, resigning active and entering the background, and the moment to act is there, before the snapshot is captured: cover the entire interface with an opaque overlay, a blank view, your logo, or a privacy screen, or hide the specific sensitive views, so the screen no longer shows sensitive content. Then, when the app becomes active again, remove the overlay or restore the views so the user sees their screen as they left it. Because the overlay is in place when iOS takes the snapshot, the thumbnail and the stored image show the overlay rather than the sensitive data. Use an overlay that fully covers sensitive content rather than relying on partial hiding, and apply it app-wide for any screen that can contain sensitive data, rather than trying to special-case individual views. The principle is simple: the system will photograph whatever is on screen at backgrounding, so make sure that is not anything sensitive.
What to watch out for
The first trap is forgetting the leak exists, since the snapshot is automatic and nothing in your code created it; any app with sensitive screens should handle it. The second is acting too late, after the snapshot is taken, rather than in the resign-active or background callback before it. The third is a partial overlay that leaves some sensitive content visible at the edges. This is on-device behavior you implement in your app lifecycle, while a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled IPA against OWASP MASVS, assesses your app's data-at-rest and leakage surface as part of the broader storage picture the snapshot file belongs to.
What to take away
- iOS captures a snapshot of an app's screen when it backgrounds, for the app switcher, and stores that image, so sensitive on-screen content is captured and persists.
- The risk is both immediate, a sensitive thumbnail visible in the app switcher, and residual, the saved image on disk, for any app that can show sensitive data.
- Prevent it by obscuring the screen with an overlay or hiding sensitive views in the resign-active or background callback, before the snapshot, and restoring it when active again.
- Use a pre-submission scan such as PTKD.com to assess your app's data-at-rest and leakage surface, and handle the snapshot in your app lifecycle.
