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: 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? 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? 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.

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.