Asking for App Permissions Without Scaring Users
By CodexierPublished 5 min read
An app that opens with three system dialogs asking for notifications, location and the camera gets three refusals, and on iOS a refusal is hard to undo. Users are not against permissions; they are against being asked for something before they understand why. This guide explains why users deny, how to ask in context, how to prepare them with a short explanation, how to handle a no, and what Apple and Google require of the wording.
Why users deny permissions
Users deny for three reasons. They do not see the benefit yet, because nothing in the app has shown value. They suspect tracking, because location and contacts have a bad reputation. Or the request interrupts what they were trying to do. All three are timing problems. The same request, shown when the user taps Scan receipt or Find nearest store, answers its own question: the reason is on the screen.
Ask in context, not at launch
| Permission | Ask when | Avoid |
|---|---|---|
| Camera | The user taps a scan or photo button | Asking during onboarding |
| Photos | Use the system photo picker, which needs no permission | Requesting full library access for one image |
| Location | The user opens a map or searches nearby | Asking for always-on location without a clear background feature |
| Notifications | After the user does something worth being notified about, such as a booking | Asking on the first screen |
| Contacts | The user chooses to invite someone | Uploading the address book by default |
Background location needs a strong justification. Google Play requires a separate declaration and both stores review it closely.
Notifications deserve special care, since Android now also requires a runtime permission for them. Ask after a moment of value: a booking made, an order placed, a follow saved. Our guide to push notifications users keep covers what to send once you have permission.
Pre-permission explanations
A pre-permission screen is your own short explanation shown right before the system dialog. It lets the user decline without burning the one real request, and it frames the benefit in your words. Keep it honest and brief, and do not imitate the look of the system dialog.
- A one-line benefit: Allow the camera to scan receipts straight into your expense report.
- What you do not do: We only use the camera while you scan. Photos stay on your device until you send them.
- A primary button labelled Continue that triggers the system dialog.
- A secondary Not now that closes the screen without asking the system.
- If the user chose Not now, ask again the next time they use the feature, not on a timer.
Handling a no gracefully
Design every feature to survive a denial. If the camera is refused, offer manual entry or file upload. If location is refused, let the user type a postcode. On iOS, once the system dialog has been declined, the app cannot show it again; the only route is to explain how to enable it in Settings and link there. On Android the dialog can be shown again, but after repeated denials the system stops showing it, so the same Settings route applies. Never block the whole app because one permission was refused unless the app truly cannot work without it.
Store rules on permission text
Apple requires a purpose string for every protected resource, shown inside the system dialog, and rejects apps whose strings are vague, such as needs access to the camera. Write what the feature does for the user. Both stores reject apps that pressure or trick users into granting access, or that request data they do not need. The permissions you request must also match your privacy labels and your privacy policy, which under GDPR must explain the purpose of each type of data; the guide to app privacy labels covers that alignment.
Vague
This app needs your location.
Clear
Your location is used to show pick-up points near you. It is not stored after the search.
Not allowed
Wording that implies the app will not work at all, when it would, or buttons designed to look like the system dialog.
When you do not need this work: an app that uses no protected resources beyond what the system pickers offer has little to design here. When permissions are central, as in scanning, delivery or field-service apps, plan the flows in the prototype before development. Our app prototype and UX design includes permission flows tested with real users. See the pricing page or book a call.
Frequently asked questions
Can we ask for all permissions during onboarding to get it over with?
You can, but you will get more refusals, and on iOS those are hard to reverse. Onboarding can mention what the app will ask for later, but the actual requests work far better at the moment each feature is used.
Is a pre-permission screen allowed by Apple?
Yes, as long as it is honest, does not mimic the system dialog and does not pressure the user. Use a neutral button such as Continue and always offer a way to decline.
What if our app genuinely needs location to work?
Say so clearly in the store listing and at the start, then ask when the user reaches the first screen that needs it. Offer approximate location if precise is not essential, and explain how to change the setting if they refuse.
Do permissions affect GDPR compliance?
Yes. A system permission is not the same as a legal basis under GDPR. You still need a lawful reason for processing the data, a clear purpose in your privacy policy, and to collect only what that purpose requires.
Design permission flows before you build
Book a short call and tell us which features in your app need permissions. We suggest when and how to ask, and what the fallback should be for each.
Book a free 15-minute call