App Onboarding
Part of Mobile app onboarding
Choosing when to request app permissions
Choose app permission timing from the feature a person is using, the access it needs and a clear path after refusal.
Request protected access when a person reaches a feature that needs it and can see what granting it will enable. First, check whether the feature can work with less access. If access is essential to the first task, explain that dependency at the task; otherwise, let them use the rest of the app.
Start with the feature
For each proposed request, record the action chosen, the capability required, the least access that supports it, and what happens after refusal. If a scanning feature needs runtime camera permission, the scan action provides context for the request. A prompt before the person encounters scanning does not.
| Situation | Timing decision | After refusal |
|---|---|---|
| The current task needs protected access | Explain the dependency as the task begins, then request the needed access. | Explain which part is unavailable and offer another useful route if one exists. |
| A later feature needs access | Wait until the person chooses that feature. | Keep unrelated tasks available. |
| A narrower system option meets the need | Use or offer that option where practical. | Continue through the narrower route if it remains available. |
The table is a product decision aid. Permission types and request mechanisms vary by resource, platform and operating-system version.
Give the request context
Name the action and access accurately. In a hypothetical receipt app, “Use the camera to scan this receipt” gives more context than “Enable permissions”. Do not imply that access alone completes the task if other steps remain.
Android's runtime-permission guidance recommends checking current permission state and requesting access when the relevant task is invoked. Where an educational explanation appears, it should offer a way to cancel. The app cannot customise Android's system permission dialog, so its own interface must provide useful context.
An early request can be appropriate when the first useful task truly depends on protected access. Explain that dependency before the prompt, and make the outcome after refusal clear.
Design the refusal path
After refusal, identify the affected feature without blocking unrelated use. Android recommends respecting the decision and preserving other functionality where possible. Check current permission state before attempting protected work, because a previous grant may have changed.
A narrower route may avoid broad access. Android's photo picker, for example, lets someone select particular images or videos without granting access to the entire media library. It helps only when selected media meets the feature's needs. Manual entry might be an alternative to scanning, but offer it only if the product actually supports it.
Write recovery text for the real consequence. “Scanning needs camera access; you can enter the details manually” fits only an app with manual entry. Otherwise, state what cannot be done and let the person leave the unavailable task.
Assess timing through task results
Record which feature led to a request, whether access was granted, and whether the person completed that feature's task. Compare eligible users under compatible platform and app-version conditions. Distinguish refusal from leaving before a request appeared. A grant rate alone does not show whether the request helped people finish.
Before release, check grant, denial, settings changes and interruption on supported devices.
Key Metrics to Assess Permission Timing
- Grant ratePercentage of users who grant permission after request
- Task completion rateProportion of users who finish the intended task after permission request
- Refusal vs. abandonmentDistinguish between users who refuse and those who leave before the request appears
- Settings changesTrack how many users change settings post-refusal
