App permission prompts: when and how to ask

The short answer

Ask for a permission at the moment the person needs the feature, not at first launch. Explain the benefit in a short message of your own first, then show the system prompt. Request only what the feature needs, and make sure the app still works sensibly if the answer is no.

Why permission timing matters

On both iOS and Android, the operating system controls the permission dialog. The app cannot restyle it. On iOS, once a person denies a request, the app generally cannot show the same system dialog again, and the person has to change the choice in Settings. Android has its own rules and they have changed between versions, so check the current documentation for the versions you support.

That makes the first request precious. An app that asks for five permissions in the first minute teaches people to tap "Don't allow" without reading. An app that asks at the moment of need gets a much better answer, because the reason is obvious.

Ask when the benefit is clear

The best time to ask is directly after the person does something that needs the permission.

• A photo app asks for camera access when the person taps the camera button.
• A delivery app asks for location when the person chooses to use their current address.
• A messaging app asks for notifications after the first conversation, not before.
• A scanner asks for camera access on the scan screen, with a line explaining why.

Use a pre-prompt message

A pre-prompt is a short screen or message from your own app that appears before the system dialog. It explains in one or two sentences what the app will do with the permission and what the person gets. It also lets people who are unsure say "Not now" without using up the one system request.

Keep it honest and specific. "Allow location so we can show shops near you" is clear. "We need your location to improve your experience" is vague and people ignore it. The wording in the system dialog also comes from a purpose string that your developer writes, so make sure it matches what the app really does. App stores can reject apps whose permission text is misleading, a point we cover in the guide on why apps get rejected.

Ask for the minimum

Request only the permissions a feature truly needs, and the narrowest version where the platform offers a choice. If the app only needs a person's approximate area, ask for approximate location. If it needs to read one photo, use the system photo picker rather than asking for the whole library where that is possible.

Fewer permissions also simplify your privacy disclosures. What you request has to match the information you give in the app store forms, covered in our guide to app privacy labels and data safety forms.

Plan for a no

Some people will always say no, and the app should still work. Design a graceful fallback for each permission.

• If notifications are denied, show reminders inside the app.
• If location is denied, let the person type an address.
• If the camera is denied, offer to upload an existing file.
• If the person later wants the feature, show a clear button that explains the step and links to the system settings.

Testing permissions properly

Test the permission flow on fresh installs and on devices that have already denied access. Test each operating system version you support, because behaviour and wording differ. Test what happens when someone grants a permission and later removes it in Settings while the app is closed.

Record the results in your test plan, the same plan that covers crashes and updates in app UX basics for first-time founders. Permission bugs are easy to miss because developers usually test on devices where everything is already allowed.

Wording a pre-prompt

Keep a pre-prompt to a short heading, one sentence about the benefit and two clear buttons. Avoid pressure such as "You must allow this". Do not use a button that looks like the system's own Allow button, because people will be confused about what they are agreeing to. Make the secondary choice calm, such as "Not now", so people who hesitate can still use the app.

Permissions that need extra care

• Location, especially in the background, because platforms and stores apply extra rules and review.
• Contacts and photo libraries, which are very personal.
• Microphone and camera, where people expect a clear reason and a visible sign when they are in use.
• Notifications, where frequency matters more than the first request.

Read the current platform documentation for each permission before launch. Rules for background access in particular change between operating system versions.

Related guides

• Mobile app development
• App Login and Authentication Options Explained
• App Privacy Labels and Data Safety Forms Explained
• App store optimisation basics
• What to build in the first version of your app
• Push notifications when and how to use them

Questions and answers

Can I show the system permission dialog again after a denial?

Generally not on iOS; the person has to change the setting in the device's Settings. Android differs by version, so check the current documentation. Either way, design a path that explains why the permission helps.

Should I ask for all permissions at first launch?

No. Asking for many permissions at once lowers the chance of a yes. Ask for each one when the person uses the feature that needs it.

What is a pre-prompt?

It is a message from your own app shown before the system dialog. It explains the benefit and lets the person choose to continue or wait, so a hesitant person does not use up the one system request.

Do permissions affect app store approval?

Yes. Stores check that permission requests and the text shown to users match what the app does. Requesting access you do not use can lead to rejection or questions from reviewers.