App Review Guidelines 2.5.1 / 2.5.2 — official guidance on screen capture protection for sensitive content

There are no public APIs available for preventing screenshots at this time.

Please file an enhancement request using the Feedback Assistant so that your request can be seen by the appropriate decision makers. If you file the request, please post the Feedback number here so we can make sure it gets routed to the right team.

Please note that filing an enhancement request does not guarantee Apple will add any requested functionality to Apple products in the future. However, with that said, filing an enhancement request is a good way to get your ideas in front of the folks who make decisions about that sort of thing.

If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why?

Thank you for the reply and for the confirmation. The acknowledgment of the absence of public APIs for screenshot prevention was actually the starting premise of our request, which we had explicitly stated in the opening of the original post. We will of course proceed with filing the enhancement request via Feedback Assistant as suggested, and we will post the FB number here as soon as it is available so it can be routed to the appropriate team. We would, however, like to respectfully revisit the two specific points of the original request that were not addressed in the reply, as they are the ones that directly impact the product decisions we need to make in the short term:

Independently of the absence of a dedicated API, is the practice of leveraging the documented behavior of UITextField with isSecureTextEntry as a wrapping container for arbitrary views — a pattern adopted both by several established open-source libraries and, in practice, by various widely distributed App Store apps — considered an acceptable use of public APIs under Guideline 2.5.1, or does it introduce App Review risk that we should avoid? For apps handling sensitive personal data that intend to align with industry standards such as OWASP MASVS-PLATFORM-3, is there official documentation or a specific recommendation on which approaches are considered safe for the prevention of screenshot and screen recording leakage?

We understand that App Review evaluates on a case-by-case basis and that general pre-approvals are not possible. However, even guidance in principle — for example, whether the pattern in question falls within the scope of 2.5.1 in terms of "unintended" use of public APIs — would be extremely useful for us to inform the product roadmap. Thank you again for your time.

Thank you for following up. Let me address your remaining questions directly.

DTS is not able to provide guidance on how App Review will evaluate a particular implementation. However, I'd note that Guideline 2.5.1 — which you cited in your original post — states that "apps should use APIs and frameworks for their intended purposes." The isSecureTextEntry property is intended for secure text input. Using it as a wrapping container for arbitrary views to prevent screen capture is not its intended purpose. The screenshot-prevention behavior you're relying on is a side effect of how secure text fields work, not a documented feature of that API. There is no guarantee that this behavior will continue to work across system software updates, and that side effect is subject to change at any time without notice.

If you haven't already, please file an enhancement request using Feedback Assistant for a public API to protect sensitive content from screen capture, and post the FB number here so it can be routed to the appropriate team.

Thank you for the definitive clarity on this point — it allowed us to close our internal evaluation regarding the use of isSecureTextEntry.

To align our path with the Apple-friendly way of addressing this use case, we would like to take this opportunity to ask for confirmation on some alternative patterns we have identified, and that we believe fall within the intended use of their respective APIs:

1. Is subscribing to UIApplication.userDidTakeScreenshotNotification in order to react to a user screenshot — for example, by displaying an overlay on sensitive screens or by logging an audit event — considered fully in line with the Guidelines and with the intended use of the API?

2. Likewise, is the use of UITraitSceneCaptureState (iOS 17+) and UIScreen.isCaptured to detect screen recording/mirroring state, applying a reactive overlay on sensitive views when the screen is being captured, considered intended use of the APIs?

3. Within the Apple developer documentation or WWDC sessions, is there reference guidance or sample code for protecting sensitive content (private chats, customer data) through Apple-aligned patterns? For example, comparing .privacySensitive(), the use of the App Switcher privacy snapshot (Tech Q&A QA1838), and any other frameworks Apple may recommend for this use case.

We will proceed in the coming days with filing the Feedback Assistant request for a dedicated API and will post the number here.

Thank you again for your support, which has been essential in guiding us toward correct choices.

Brief follow-ups on your three new questions:

1. UIApplication.userDidTakeScreenshotNotification — yes, observing that notification and reacting (with an overlay or an audit log) is its intended use. For your apparent use case I think it's worth pointing out that the notification is posted after the screenshot has been captured by the system. The callback you provide runs after the screenshot is already in Photos, so an overlay you apply in response can hide your UI for subsequent screenshots but can't redact the one that triggered the notification. For audit logging this fits. It is not a prevention mechanism — by the time your handler runs, the screenshot has already been saved.

2. UIScreen.isCaptured and UITraitSceneCaptureState (iOS 17+) — yes, observing the property or trait and reacting to capture state is the intended use of those APIs. They reliably reflect the system's view of capture state for capture mechanisms iOS knows about (Control Center screen recording, AirPlay mirroring, Sidecar / Continuity capture, and so on). The relevant caveat is the inherent race window — the property or trait updates around the time capture begins, but sensitive content rendered on-screen at the moment capture starts may be visible in the window before your handler runs. Same shape as the screenshot notification: fits audit and reactive UI updates, but it is not a prevention mechanism — anything visible on screen when capture begins is in the captured stream before your handler can react.

3. Documentation pointers. Apple hasn't published a guide on protecting sensitive content from screen capture. Each of the APIs you mentioned — View.privacySensitive(_:), UIApplication.userDidTakeScreenshotNotification, UIScreen.isCaptured, UITraitSceneCaptureState, and the App Switcher snapshot pattern documented in QA1838 — has its own documentation describing what that API does. None of that documentation frames them as parts of a "screen capture protection" pattern.

Thanks in advance for the FB number once you've filed.