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.