On Android you can mark a screen so it cannot be captured at all. iOS has no direct equivalent, but it does give you something useful: the ability to detect that the screen is being recorded or mirrored, and to know after the fact that a screenshot was taken. That changes the playbook. For screen recording and AirPlay mirroring, you can observe a capture flag and hide sensitive content while capture is active; for screenshots, you can react once one happens but not block it. Knowing which is which, and what iOS lets you do in each case, is the key to handling sensitive content sensibly. Here is how iOS screen-capture and screenshot detection work and how to use them well.
Short answer
iOS lets you detect screen capture and screenshots, though not prevent screenshots outright. Per Apple, UIScreen's isCaptured property is true while the screen is being recorded or mirrored, and a capture-change notification lets you react, so you can hide sensitive content while capture is active. For screenshots, a screenshot notification fires after the user takes one, so you can respond, log it, warn, or obscure content afterward, but you cannot block the screenshot. Unlike Android's ability to mark a screen non-capturable, iOS detection is largely reactive, so the approach is to obscure sensitive content during active capture, respond to screenshots after the fact, and limit displaying highly sensitive data where capture cannot be prevented.
What you should know
isCapturedsignals active capture: recording or mirroring in progress.- A notification lets you react to capture changes: hide content while captured.
- A screenshot notification fires after the fact: you cannot prevent it.
- iOS has no FLAG_SECURE equivalent: detection is largely reactive.
- Obscure sensitive content during capture: and respond to screenshots.
How do detecting capture and screenshots differ?
One is live and preventable in effect, the other after the fact. The table contrasts them.
| Aspect | Screen capture (recording/mirroring) | Screenshot |
|---|---|---|
| Signal | isCaptured true; capture-change notification | A notification after the screenshot |
| Timing | While capture is active, ongoing | After the screenshot is already taken |
| What you can do | Hide sensitive content during capture | React afterward; cannot block it |
| Use | Obscure content while recording or mirroring | Log, warn, or obscure post-capture |
The two cases are genuinely different. Screen capture, recording the screen or mirroring it over AirPlay, is an ongoing state, and iOS exposes it through the isCaptured property, which is true while capture is happening, along with a notification when that state changes. Because it is ongoing, you can react in real time, hiding or obscuring sensitive content for as long as capture is active and restoring it when capture stops, which in effect keeps sensitive content out of a recording. A screenshot is a single instantaneous event, and iOS notifies you after it has been taken, so you cannot prevent it, only respond, by logging the event, warning the user, or obscuring content going forward. Recognizing that capture is a state you can react to during, while a screenshot is an event you learn about after, is what determines what protection is realistically possible in each case.
Why can you only react, not prevent?
Because iOS does not provide a general way to block screen capture or screenshots. Android offers a flag that marks a window so the system excludes it from screenshots and screen capture, a true prevention mechanism, but iOS has no direct, official equivalent for arbitrary content, so you cannot simply declare a screen uncapturable. What iOS gives you instead is visibility: the isCaptured state and the screenshot notification let your app know capture is happening or has happened. For active capture, that visibility is nearly as good as prevention for the content's purpose, since you can hide sensitive views while isCaptured is true, so the recording or mirror shows your obscured state rather than the data. For screenshots, the visibility comes after the event, so true prevention is not available, and you are limited to responding. This is why the iOS approach is framed around detection and reaction rather than a blanket block, and why, for the most sensitive content, the realistic strategy also includes not displaying it in a form that a single screenshot would fully expose.
How do you use detection well?
React to capture in real time, respond to screenshots, and limit exposure where you cannot prevent it. Observe the capture state and its change notification, and while the screen is being recorded or mirrored, hide or obscure sensitive content, replacing it with a placeholder or blur, then restore it when capture ends, so sensitive data stays out of recordings and AirPlay mirrors. For screenshots, handle the screenshot notification to respond appropriately for your context, logging the event for sensitive screens, warning the user, or obscuring content afterward, while accepting that the screenshot itself cannot be stopped. For your most sensitive data, design so that no single screen, hence no single screenshot or frame, fully exposes it, and consider measures like watermarking content with the user's identity to deter sharing, since you cannot prevent capture outright. Combine this with handling the app-switcher snapshot when backgrounding, a related but separate concern. The principle is to use iOS's capture visibility to obscure sensitive content during active capture, respond sensibly to screenshots you cannot block, and reduce how much any single captured frame can reveal.
What to watch out for
The first trap is expecting a FLAG_SECURE equivalent on iOS and assuming you can block screenshots; you cannot, so detection is reactive. The second is handling screenshots but ignoring active screen recording and AirPlay mirroring, which the isCaptured state lets you obscure in real time. The third is relying on detection alone for the most sensitive content, rather than also limiting what a single frame exposes. This detection is implemented in your app, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled IPA against OWASP MASVS, assesses your app's handling of sensitive data and its leakage surface, while the capture handling is yours to build in code.
What to take away
- iOS lets you detect screen capture and screenshots but not prevent screenshots:
isCapturedand a capture-change notification signal active recording or mirroring, and a screenshot notification fires after the fact. - Because capture is an ongoing state, you can hide sensitive content while
isCapturedis true; because a screenshot is an instantaneous event, you can only respond after it. - Unlike Android's FLAG_SECURE, iOS has no general block, so obscure sensitive content during active capture, respond to screenshots, and limit how much any single frame reveals for the most sensitive data.
- Use a pre-submission scan such as PTKD.com to assess your app's sensitive-data and leakage surface, and build capture detection and obscuring in your code.
