1. Permission is a contextual product decision
A permission prompt should appear when the user understands the feature. Asking for camera, media or notifications during onboarding may be convenient for developers, but it often feels invasive to users.
A better flow explains the value first, opens the system prompt second and handles denial third.
- Ask permission near the action that needs it.
- Use clear pre-prompt copy when context is not obvious.
- Avoid requesting permissions for future features.
- Respect denial and keep the app usable when possible.
- Document permission rationale for support and review.
2. Android and iOS permissions are similar only on the surface
Android and iOS differ in prompt timing, permission categories, limited media access and notification rules. A single generic message can miss important platform expectations.
Release validation should include both platforms because a flow that feels fine on one can be confusing on the other.
- Review platform-specific text for camera, media and notifications.
- Test denial, partial access and later enabling in settings.
- Confirm Android notification behavior for recent OS versions.
- Handle limited photo library access when relevant.
- Keep screenshots and store privacy metadata aligned with real permissions.
3. Denial is a state the app must support
Users may deny permissions for good reasons. The app should not crash, loop prompts or show cryptic errors. It should explain the consequence and offer a path forward when the feature is still important.
A denied permission can still lead to a useful alternate flow.
- Show a clear message when a feature cannot continue without permission.
- Offer manual alternatives where business rules allow.
- Do not repeatedly trigger the system prompt after denial.
- Guide users to settings only when that action is genuinely needed.
- Track denial-related drop-off without collecting unnecessary personal data.
4. Permissions belong in release checks
A permission change can affect store review, user trust and production behavior. It should be reviewed before release just like API changes, privacy text and analytics events.
This is especially important when native configuration changes require a new binary.
- Review requested permissions before every store release.
- Remove permissions left from experiments.
- Test first-use flow on a clean install.
- Align privacy policy and store declarations with real behavior.
- Record which build introduced permission changes.
How to use this article
Treat this page as a decision aid. Use it with the related hub, checklist or service route when the topic affects production, customer experience, deployment, security or business continuity.