Better mobile privacy: follow the data through every flow

Better mobile privacy comes from following one piece of data through a real user task and cutting everything the task does not need. Ask where the data enters, which components can see it, where it travels and what is left when the task ends. Then replace broad access with the narrower tools both platforms now offer, such as pickers, approximate location and limited access, and test the result with synthetic data on Android and on iOS. The goal is a smaller data flow you can show working, including after someone denies access or changes their mind.

Start with one flow

Pick a flow that matters to your users: attaching a document, finding a nearby branch, signing in or contacting support. Ask one narrow question. For example: can someone attach the file they chose without the app seeing anything else in their storage?

Then map every place the data goes. Include the screen, any local copy, the network request, the receiving service, and the support and analytics records. Treat crash reports and diagnostic exports as separate destinations. If a third-party SDK takes part, include it even if your own code never reads the data.

For each field, name the task it serves and the least detailed value that still works. A branch finder may need a district, not a precise position. A support record may need an error category, not the text someone typed.

Use the narrower tools the platforms give you

Since 2020, both platforms have added ways to share less. Many features that once needed a broad permission now work without one.

Android

• Pick, do not browse. The photo picker returns only the images or videos the person selects, with no storage permission. The Storage Access Framework does the same for documents.
• Ask for coarse location. From Android 12, people can grant approximate location even when you request precise. Design features to work with ACCESS_COARSE_LOCATION and ask for precise only when the task truly needs it.
• Handle refusal. Android’s guidance is to respect the decision and degrade gracefully. Offer manual entry or a narrower feature instead of asking again.

A minimal photo selection with the Jetpack picker needs no permission at all:

val pickMedia = registerForActivityResult(ActivityResultContracts.PickVisualMedia()) { uri ->
    if (uri != null) attach(uri) else showManualOption()
}
pickMedia.launch(PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly))

iOS

• Use out-of-process pickers. PHPickerViewController returns selected photos without photo library permission, and CNContactPickerViewController returns selected contacts without contacts authorisation.
• Respect limited access. People can share a subset of photos, and from iOS 18 a subset of contacts. Treat fewer results as a choice, not an error.
• Work with approximate location. People can switch off precise location for your app; design for that state.
• Check your SDKs. Compare each SDK’s privacy manifest with your App Store privacy details, and never replace a refused tracking permission with another identifier used for the same purpose.

Clean up the quiet leaks

The biggest privacy gaps are often not in the feature at all. They sit in logs, crash reports, analytics events and screens that anyone nearby can capture.

App protection helps where hostile changes or runtime interference could undermine a sensitive flow. Otukan Application Security provides code obfuscation, anti-tampering and runtime self-protection, engineered separately for Android and iOS. It blocks screenshots and screen recording of screens marked sensitive on Android, and on iOS detects active screen recording and mirroring and masks sensitive content while it is active. Those controls protect a boundary; deciding which data is necessary stays with your team. For the control view, see data loss prevention.

Test the awkward paths

The happy path rarely fails. Privacy fails after the person changes their mind.

1. Create a synthetic record that is easy to spot in traffic and logs but resembles no real person.
2. Run the flow with access granted, denied and limited, then revoke access in Settings and repeat.
3. Sign out, reinstall and update; check what survives each step on the device and on the server.
4. Request deletion and check the receiving systems, not only the confirmation screen.
5. Record the build, device, OS version, expected result and actual result for each platform separately.

Release checklist

• Every collected field has an agreed purpose and an owner.
• Pickers, coarse values or limited access are used wherever the task allows.
• Denial and later changes have usable, tested outcomes.
• Logs, crash reports and analytics contain no unnecessary content or direct identifiers.
• SDK privacy manifests and store disclosures match the release.
• Deletion is tested end to end.
• Android and iOS results are recorded separately.

For the legal side of privacy by design, including who is responsible when a supplier builds the app, see GDPR privacy by design for mobile apps.

Further reading

• Minimize your permission requests — Android Developers
• Photo picker — Android Developers
• User privacy and data use — Apple Developer
• Privacy manifest files — Apple Developer Documentation
• App privacy details on the App Store — Apple Developer