Evaluate mobile data loss prevention by tracing every route customer data can take out of your app once it is on screen, then checking which routes each platform lets you close, detect or only mask. The routes are screenshots, screen recording and mirroring, the clipboard, the keyboard and the preview images the system takes when users switch apps. Otukan controls each route on Android and iOS, including Flutter and React Native apps, on the screens and fields you mark. Android can block capture outright; iOS allows detection and masking. The strongest control of all sits on your server: data it never sends to the device cannot leak from it.
Leak routes and the flows they touch
Data loss on mobile rarely looks like a breach. A customer screenshots a statement and the image syncs to a shared album. A card number is copied and another app reads the clipboard. A keyboard learns an account number and suggests it later. Each route is ordinary behaviour that becomes a leak on the wrong screen.
Flows at risk
| Flow | Data on screen | Route most likely to leak it |
|---|---|---|
| Card details and PIN reveal | Full card number, security code | Screenshot, clipboard |
| Statements and transaction history | Balances, payees, references | Screenshot, app-switcher preview |
| Identity and onboarding | Document images, dates of birth | Screen recording, mirroring |
| Health and insurance records | Diagnoses, policy numbers | Screenshot, clipboard |
| Sign-in and one-time codes | Passwords, codes | Keyboard learning, keylogging |
The boundary you are defending
The boundary is your app’s interface and the system services it hands data to. Once content reaches a screenshot, a clipboard entry or a keyboard’s memory, it is outside your app and outside your control. Data loss prevention keeps the high-value content on the inside of that line.
Control fit
The app, the operating system and your backend each own part of the answer. The table shows who does what.
| Route | Operating system | Your app with Otukan | Your backend |
|---|---|---|---|
| Screenshots | Android can exclude marked windows from capture; iOS notifies after the event | Marks screens, masks content, applies your policy | Keeps a record of events on marked screens |
| Recording and mirroring | iOS reports when capture is active; Android excludes secure windows | Masks content while capture is active | Receives the capture signal |
| Clipboard | iOS lets apps keep a copy on the device and set it to expire; recent Android versions stop background apps reading the clipboard and let apps mark a copied value as sensitive | Limits copying from marked fields | Sends only the data the screen needs |
| Keyboard | Android fields can ask the keyboard not to learn from input; iOS secure text fields use the system keyboard and skip learning, and apps can decline third-party keyboards | Applies the right flags to marked fields; flags non-system keyboards on Android | Treats a keyboard-risk signal as account risk |
| App-switcher previews | Captures an image as the app leaves the foreground | Covers marked screens first | Nothing further needed |
The backend’s role is easy to overlook. Masking a full card number on screen matters less when the server sends only the last digits. The strongest data loss design removes data from the device before any control has to guard it.
On iOS, privacy manifests describe which data and system features your app uses. Guidance on avoiding manifest conflicts is on preventing conflicts with iOS privacy manifests.
Evaluation
Judge a data loss prevention offer on three things: per-platform honesty, evidence on your own flows and the effect on real users.
Supported platforms
Ask for each route by platform, because the answers differ: Android lets an app block capture of a screen, while iOS lets it detect capture and mask content. Otukan states for each route whether it blocks, detects or masks on Android and on iOS, and treats Flutter and React Native screens with the same per-platform rules.
Evidence
In an authorised lab, take a screenshot, start a recording, copy a marked field and switch apps on each marked screen, and confirm the expected block, mask or signal. On a legitimate device, the same journey with no capture active should show the screen normally. After each protected release, repeat install, update, sign-in and the marked flows, with OS versions, devices, results and reviewer recorded.
User impact
Marking too much frustrates people who need to share a reference number with a partner or send support a picture of an error. Mark the screens and fields that hold regulated or high-value data, check them with the assistive settings your users rely on and widen coverage only when the evidence supports it.
For the privacy background, see better mobile privacy and privacy by design for mobile apps.
The package and memory controls that complete the picture are covered on code and data protection. For content capture in media apps, see streaming and media application security.