iOS gives you no public API to fully prevent screenshots the way Android's secure window flag does, so in SwiftUI you cannot simply block a screenshot outright. What you can do is detect when a screenshot or screen recording happens and react, and use a well-known workaround: content placed inside a secure text entry field's layer is excluded from screen captures, showing up blank in a screenshot or recording. Commercial libraries such as ScreenShieldKit package this technique for you. None of it stops someone photographing the screen with another camera, so for DRM or banking apps, treat screenshot prevention as a deterrent, keep truly sensitive data off the client, and protect it server-side.
Short answer
There is no official iOS API to prevent screenshots, so full prevention in SwiftUI is not possible, only deterrence and detection. Per Apple, you can detect a screenshot through the user-did-take-screenshot notification and detect recording via UIScreen isCaptured, then obscure content. The common prevention workaround puts your view inside a UITextField with secure text entry enabled, whose layer iOS excludes from capture, and libraries like ScreenShieldKit wrap this. Per the OWASP MASVS, such controls raise cost but do not replace protecting data server-side, since a second camera defeats any on-screen method. Use these to deter casual capture, not to guarantee content cannot be saved.
Is it possible? What iOS offers
The honest answer to whether SwiftUI can prevent screenshots is no, not in the sense of a supported API that blocks the capture, because Apple does not provide one. Unlike Android, which has a window flag that marks content secure and produces a black frame in screenshots and recordings, iOS has no public equivalent that outright prevents a user from taking a screenshot of your app. So any claim of true screenshot prevention on iOS is either a detection-and-react approach or an undocumented workaround, not a first-class platform feature.
What iOS does offer is detection and a couple of indirect techniques. You can be notified when a screenshot is taken and can check whether the screen is being captured or recorded, which lets you respond, for instance by hiding sensitive content. And there is a long-standing workaround using secure text entry that excludes a view's layer from capture. Understanding this distinction, detection and workarounds versus a real prevention API, sets correct expectations before you build, especially for DRM or banking use cases where the difference matters.
The secure text entry workaround
The most common prevention workaround relies on how iOS treats a secure text entry field. When a UITextField has secure text entry enabled, its rendered layer is excluded from screenshots and screen recordings, appearing blank in the captured image, because the system protects password-style input from capture. Developers exploit this by placing the content they want to protect inside that secure layer, so the sensitive view inherits the same exclusion and shows up empty in a screenshot. It works in UIKit and can be bridged into SwiftUI.
Be clear-eyed about what this is. It is an undocumented behavior, not a supported prevention API, so Apple could change it in any release, and it protects only the specific view you place inside the secure layer, not the whole screen. It also does nothing against a second camera. Treat the secure text entry trick as a deterrent that hides content from casual digital capture on that view, with the understanding that it is fragile and narrow, and never as a guarantee that the content cannot be captured by other means.
ScreenShieldKit and commercial options
Because the secure text entry workaround is fiddly and fragile, commercial libraries exist to package it, and ScreenShieldKit is a common one. These SDKs wrap the underlying capture-exclusion technique into an easier-to-use component you can apply to views, and they are marketed to apps with strong content-protection needs such as DRM and paid media. Using one saves you from maintaining the workaround yourself and can make it more robust across iOS versions than a hand-rolled implementation.
What a commercial library does not do is change the fundamental limits. It still relies on the same platform behaviors that Apple does not formally guarantee, so it can be affected by iOS changes, and it still cannot stop someone photographing the screen with another device. So evaluate a tool like ScreenShieldKit as a way to implement the deterrent more reliably and with less effort, weighing its cost against how much casual-capture protection your content needs, rather than as a solution that makes your content truly uncapturable. The ceiling on what is achievable is set by the platform and the analog hole, not by the library.
Detecting screenshots and recording
The supported path, rather than a workaround, is detection, which lets your app react when capture happens. iOS posts a notification when the user takes a screenshot, so you can respond after the fact, for example by logging the event, warning the user, or clearing sensitive content from view. For screen recording and mirroring, you can check whether the screen is currently captured through the capture status and observe changes to it, then obscure protected content while capture is active.
Detection does not prevent the capture, and it is important to be precise about that: by the time the screenshot notification fires, the screenshot already exists. Its value is in responding, adding friction, obscuring content during recording, and creating a record, rather than blocking. For many apps, combining detection with the secure text entry technique for the most sensitive views gives a reasonable deterrent: recording is met with a blanked screen via the capture check, and static screenshots of protected views come out empty. Just keep in mind that both are deterrents layered on a platform that permits screenshots.
The limits: the analog hole and fragility
Two hard limits bound everything above. The first is the analog hole: whatever a user can see, they can photograph or film with a second device, and nothing in iOS is involved to block that, so no on-screen technique can protect content a viewer can see. The second is fragility: the secure text entry exclusion is undocumented, so a future iOS version could change how it behaves, and detection depends on APIs and behaviors that also evolve. Building critical protection on either is building on ground that can shift.
These limits are why screenshot prevention on iOS is a deterrent rather than a guarantee. They do not make the techniques worthless, since deterring casual digital capture is a real and useful effect, but they cap what the techniques can promise. Any design that assumes protected content truly cannot leave the device, because you applied a capture-exclusion trick, is ignoring both the analog hole and the possibility that the trick stops working. Realistic protection accepts these limits and plans for the case where content is captured anyway.
Remediation for DRM and banking apps
For DRM, banking, and similar apps that drew you to this question, the durable approach combines on-screen deterrence with real protection elsewhere. Use detection and, for the most sensitive views, the secure text entry technique or a library like ScreenShieldKit to deter casual capture, and add visible or invisible watermarking tied to the user so that content which does leak can be traced, which discourages intentional capture more than a blanked view alone.
The real protection, though, is not putting content on the client that cannot tolerate capture, and enforcing access server-side. Keep high-value data and full media on the server, deliver to the device only what the user is entitled to see and only when they are authorized, and for protected media use established DRM designed for the purpose rather than a screenshot trick, while recognizing even DRM does not beat a camera. Assume the client can be compromised and the screen can be captured, and design so that a captured screenshot does not expose anything you cannot afford to lose.
Approaches and their limits
Seeing the options together clarifies what each can and cannot do. The table below compares them.
| Approach | What it does | Limitation |
|---|---|---|
| Native prevention API | Does not exist on iOS | Cannot block a screenshot outright |
| Secure text entry layer | Excludes a view's layer from capture | Undocumented, fragile, per-view |
| ScreenShieldKit or similar | Packages the exclusion technique | Paid, same platform and camera limits |
| Screenshot and recording detection | Reacts after or during capture | Responds, does not prevent |
| A second camera | Photographs the screen | Defeats every on-screen method |
Read the table by promise: none of these prevents capture in the way the word suggests, so choose them as deterrents and put real protection server-side.
Implementation checklist
Working through these steps builds a realistic deterrent and real protection. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Set honest expectations | Treat prevention as a deterrent, not a guarantee | [ ] |
| Detect capture | Use the screenshot notification and capture status | [ ] |
| Protect sensitive views | Secure text entry layer or a library like ScreenShieldKit | [ ] |
| Keep secrets off the client | Do not ship what must never be captured | [ ] |
| Protect server-side | Authorize access and deliver only viewable content | [ ] |
| Watermark | Tie content to the user to trace and deter leaks | [ ] |
The step that matters most is keeping genuine secrets off the client, because every on-screen technique above it can be defeated by the analog hole or an iOS change.
Assess what your app exposes
Because the real question is what your app puts on a device where the screen can be captured, seeing what your build actually exposes helps more than assuming a capture trick covers it. Knowing where sensitive data is stored and what ships in the app is the input to deciding what must stay server-side.
A scanner like PTKD.com analyzes your build and reports issues such as insecure data storage, leaked keys and secrets, and over-broad permissions by severity, mapped to OWASP MASVS, so you can see what would be exposed if a screenshot or a compromised device reveals it. To be clear about the boundary: PTKD does not prevent screenshots, which nothing fully can on iOS, and it does not implement a capture-exclusion technique. It helps you understand and reduce what your app exposes so you are not relying on a fragile trick to protect it.
What to take away
- iOS has no public API to fully prevent screenshots, so full prevention in SwiftUI is not possible, only detection and deterrence.
- The common workaround places content inside a secure text entry field's layer, which iOS excludes from capture, but it is undocumented, fragile, and per-view.
- Commercial libraries like ScreenShieldKit package that technique more robustly, but they share the same platform limits and cannot beat a second camera.
- Use the supported screenshot and recording detection to react and obscure content, understanding that detection responds rather than prevents.
- For DRM and banking apps, keep real secrets off the client, protect data server-side, add watermarking, and assess what your app exposes with a tool like PTKD.com.
