A person opens a mobile product to do something: capture a receipt, share a location, record a voice note, attach a document, scan a code, or connect a device. Then the operating system interrupts with a permission prompt.
That interruption is not a technical footnote. It is a product moment.
The person is deciding whether the product has earned access to something private on their device. They need to understand what access is being requested, why this action needs it now, what happens if they say no, and whether there is another way to reach their goal. The product has only a few seconds of context to make that decision feel reasonable.
A dependable mobile product asks for the smallest necessary access at the moment a person chooses the feature, then keeps the feature understandable whether access is granted, denied, or later changed.
That is a shared responsibility. Product defines the customer outcome. Design makes the choice legible. Engineering requests and checks access at the right boundary. Quality proves the experience across the states a person can actually create.
Start with the job, not the permission
“We need camera access” is an implementation statement. It is not yet a customer reason.
Start with the job a person came to do. A camera might let someone scan a barcode, capture a proof-of-delivery photo, or add a profile picture. Photos access might let them attach an existing receipt. Location might find nearby pickup points or make a delivery estimate more accurate. Each job has a different value, different risk, and sometimes a different lower-access alternative.
This distinction changes the product conversation. Instead of asking, “When should we request CAMERA?” ask:
- What is the person trying to complete right now?
- What exact access is necessary for that step?
- Can they still make useful progress without it?
- What should the product do if they change their decision later?
Android's guidance is unusually direct: request runtime permissions as late in the flow as possible, associated with the specific action that needs them. Its example is waiting until someone presses the audio-message button before asking for microphone access. Android's permissions overview also recommends requesting only the permissions needed for that action.
Apple gives the same product signal from the other direction: request sensitive device or user data only when the app needs it, provide a purpose string that explains why, and offer reasonable fallback behavior when access is not granted. Apple's privacy guidance makes timing and fallback part of the expected experience.
An app that asks for everything on first launch turns a future feature into an unexplained demand. An app that waits until the person chooses “Scan receipt” can connect the system prompt to an intention they already understand.
Earn the prompt with immediate context
The operating-system dialog carries its own wording and controls. Your product controls the moment before it.
Use that moment to explain the value in plain, feature-specific language. “Allow camera access so you can scan the receipt and prefill this expense” is concrete. “We need permission to improve your experience” is not. The first connects access to a visible outcome. The second asks someone to trust a vague future benefit.
The explanation does not need to be a long interstitial. It may be a concise label beside an action, a short supporting sentence in a bottom sheet, or clear copy immediately after the person taps the feature. What matters is that it matches the next system request and does not overstate what the product will do.
Keep the promise narrow:
- name the capability in a way the person recognizes;
- link it to the action they just chose;
- say what will happen after access is granted; and
- do not imply broader collection, retention, or sharing than the feature actually requires.
This is not a copywriting exercise separate from the implementation. On Apple platforms, the system prompt includes a usage-description string provided by the app; Apple's protected-resources documentation describes that requirement. Treat the product explanation, the platform purpose string, and the feature behavior as one contract. If they describe different things, the person has no reliable way to decide.
Ask for the smallest useful scope
A request can be technically valid and still be more access than the feature needs. That creates customer hesitation, more denial paths, and a harder product to explain.
For each feature, identify the least access that can produce its immediate outcome. If a person wants to attach one existing image, use the platform path that lets them choose an item rather than assuming the product needs their complete photo library. If they want to share a place once, consider whether a one-time selection or manual address entry can meet the job. If a dependency brings a permission, confirm that the product genuinely uses the capability the dependency declares.
Android specifically calls out dependencies: a library's permission requirements become the app's requirements from the person's point of view. Its best-practices guide advises reviewing those dependencies and avoiding unnecessary access. That deserves a product-level review, not only a manifest review.
Minimal access also makes the product more resilient. A smaller request is easier to explain, easier to test, and less likely to turn one declined option into a blocked workflow. It forces a useful design question: is access essential to the outcome, or merely convenient for the first implementation?
Design “not now” as a real state
“Denied” is not an exceptional branch. It is a normal customer decision.
Some people will prefer not to share access. Some will be on a shared device. Some will not understand the request yet. Some will have a policy that disables it. Some will deny it and return later after seeing the feature's value. A dependable product leaves those people with an intelligible next move.
Choose the response deliberately:
- Offer an alternative when the job can still be completed another way, such as typing an address instead of using location or selecting a file instead of taking a photo.
- Explain the boundary when the feature genuinely cannot work without access. State the immediate consequence, not a generic failure.
- Let the person try again in context when a second request is appropriate, after they have chosen the feature again and have better information.
- Guide them to settings only when that is the actual recovery path, and explain what to change there without making it feel like an error they caused.
Do not turn denial into a dead end or a repeating prompt. Android's guidance recommends explaining the request at the time it is made and, where relevant, in a follow-up experience after denial. It also notes that users can change runtime-permission decisions in settings. The product should be able to handle that change gracefully, not assume the answer made today will remain true tomorrow.
The distinction matters for support too. “Camera unavailable” is an observation. “To scan a receipt, allow camera access in Settings—or attach a photo from your files instead” is a useful outcome. The latter gives customer support, design, and engineering the same truth to work from.
Recheck access where the feature acts
Permission is not a one-time onboarding event. It is a current condition.
Someone can revoke access in device settings, choose a more limited scope, switch account context, restore the app on a new device, or use a system version with a different access model. Code that checked a permission weeks ago cannot safely assume it still has it when a feature acts now.
Check at the boundary where access is needed, then make the resulting state visible in the feature. On Android, the platform guidance says not to assume runtime access was previously granted: check before each restricted-data access or action. That is an engineering practice with a direct product consequence: the interface must be ready to describe a changed decision without confusing it with a broken feature.
For sensitive hardware such as camera and microphone, make active use understandable too. Android recommends a continuous indication when the system does not already provide one. A person should not need to infer that a capability is active from a hidden background state.
Test the decision, not only the allowed path
The happy path is easy to demonstrate: grant access, complete the feature, move on. The product promise is proven in the other paths.
Build a compact test matrix for every permission-protected feature:
| Customer state | What to verify | | --- | --- | | Not yet asked | The prompt appears only after the feature is intentionally chosen. | | Granted | The feature completes the stated job and does not request unrelated access. | | Denied once | The product explains the effect and offers the intended alternative or recovery. | | Denied permanently or restricted by policy | The settings guidance is accurate and the feature remains understandable. | | Revoked after prior use | Returning to the feature detects the change and avoids a crash, silent failure, or misleading success state. | | Partial or limited scope | The product respects what is available and names the limitation honestly. |
Run this matrix on supported operating-system versions and with the actual libraries included in the product. Android's guidance explicitly recommends testing combinations of permissions turned on and off; the customer experience should be part of that test, not an afterthought once the API call stops throwing an error.
Track the product signal as well. High denial alone does not prove a problem: perhaps people rightly do not want a capability. But compare the request rate, grant rate, feature completion, alternate-path completion, repeat prompts, and permission-related support contacts. A sudden drop after a new library, a changed prompt, or an early onboarding experiment tells the team where the contract may have drifted.
Make the request feel chosen
Mobile permissions protect a person's device, data, and attention. A product cannot remove that interruption—and should not try to hide it. It can make the interruption feel proportionate to a choice the person just made.
Anchor the request to a real job. Explain the immediate value. Ask for no more than the feature needs. Design a useful path for “not now.” Recheck the boundary every time the feature acts. Then test the decision states with the same care as the success state.
The result is more than a higher chance of a tap on “Allow.” It is a product that treats access as something a person chooses, not something the app assumes.
If your next mobile product needs strategy, design, engineering, and quality to agree on the choices behind a sensitive feature, bring BugSquad the challenge.