Mobile app development / DIJION
Explaining value before asking for mobile permissions
A decision plan for contextual camera, location and notification requests, including denial and later revocation.
A newly opened app requesting several permissions asks people to make decisions about features they have not yet understood. A clearer flow connects the current task with the access it requires. Instead of treating the prompt as an acceptance-rate contest, design what happens when permission is not granted.
Check whether the access is necessary
In an illustrative nearby-places screen, automatic location may help while manual city selection completes the same task. A camera action may have a supported file-selection alternative. Check these choices against current platform access rules; permission types do not all behave alike.
Connect the request to a user-initiated action
Android guidance recommends asking in context and adapting gracefully after denial. An example sequence is: the person chooses Show nearby, understands why access is needed, then sees the system request. Keep any explanation concise and avoid controls that impersonate the operating system’s prompt.
Scroll the table horizontally to see all columns.
| Feature | Brief explanation | If denied |
|---|---|---|
| Nearby places | We will use your location to find nearby places. | Choose a city manually |
| Add a photo | Camera access is needed to take a new photo. | Offer supported file selection |
| Reminder | You can receive your chosen reminder as a notification. | Show the reminder in the app |
Make denial a designed state
Do not repeatedly reopen the same request after denial. Explain which feature is unavailable and which alternatives remain. Closing an educational explanation should not prevent use of the app. Restricting a particular feature and blocking the entire product are different decisions.
Include settings changes and revocation
People can remove access in system settings. Reading permission once at first launch does not establish permanent authorization. Explain why a trip to settings is useful, then reassess the actual state on return. Do not assume a previous grant covers an expanded request.
Prepare a test card
- Browse a clean installation without entering the permission-dependent feature.
- Deny the first request and complete the alternative task.
- Revoke access in system settings and return to the app.
- Background the app while the prompt is open and verify the state on return.
Document the access type, request moment, explanation, denial alternative and return-from-settings behavior together. These examples do not describe permissions used by a particular Dijion product. They provide a practical plan that a product team can complete for its own context.