Request a device permission when the user understands the task that needs it, and define what remains possible if access is denied or later revoked. Camera, location and notification permissions serve different purposes. A single introductory request for everything makes the product harder to understand and leaves important recovery paths unspecified.
Let’s plan your app permission paths.
Bring your workflow and the decisions you need to make. We’ll help you clarify requirements, review the trade-offs and define a practical next step.
Connect each permission to a user task
Write a permission inventory: capability, purpose, trigger, fallback and owner. If the app can complete a task through manual entry or a system picker, consider that path before requesting broader access.
For example, a hypothetical delivery app might need location during an active assignment, while a customer browsing past orders may not. Specify the distinction instead of attaching permission requests to every sign-in.
Plan the state matrix
| Permission state | Product behaviour to agree | Scenario to test |
|---|---|---|
| Not requested | Explain the relevant feature before prompting | User explores without granting access |
| Granted | Use access only for the intended task | Unrelated screens do not trigger collection |
| Denied | Show a useful alternative or limitation | Task can be cancelled without getting trapped |
| Restricted or unavailable | Explain the device limitation appropriately | Unsupported hardware or managed device |
| Revoked later | Detect loss and stop relying on old access | Permission changed outside the app |
| Limited access | Operate within the actual scope | Only selected resources are available |
Check the current platform documentation for the exact permission type and supported versions. States differ by capability and operating system; this matrix is a product-planning aid, not a platform API specification.
Avoid a loop of repeated requests
When a request is denied, do not repeatedly reopen the same prompt without useful context. Explain the affected feature and provide a supported settings path where appropriate. Keep general browsing and unrelated tasks available when they do not require that capability.
Do not show a granted status as evidence that a business action completed. Camera access does not prove a photo was captured, and location access does not prove an address was selected correctly.
Test changes outside the app
Start a task, change the permission in system settings and return. Verify pending work, error messages and fallback behaviour. Include account switching and shared-device conditions if the product supports them.
Review analytics and logs as part of this test. Permission troubleshooting should not result in collecting raw location history or media beyond the agreed purpose.
Permission questions
Should all permissions be required to use the app?
Only make a capability mandatory where the core task genuinely depends on it. Explain that boundary and avoid blocking unrelated functionality.
Does permission approval establish every necessary consent?
No. Device access and the organisation's data-processing responsibilities are separate questions. Define the applicable requirements with the responsible policy owner.
Use the mobile backend scope guide to connect device behaviour to server responsibilities, then discuss the permission inventory with Drema's app team.
