Ask for push and location permissions with context first

Mobile apps rely on system permissions for many of their best features: push notifications for reminders, location for nearby results, the camera for scanning and contacts for finding friends. The operating system controls the prompt, and users only see it a limited number of times. Permission priming means asking at the right moment and explaining the reason first, so the request makes sense. It fits any mobile app whose core value depends on a permission.

Why it works

People say yes when they can see what they get. A location prompt that appears on launch, before the user has seen a single screen, looks like data collection. The same prompt right after the user taps “Find stores near me” looks like the obvious next step. The request now matches the user’s own goal.

There is also a hard constraint. According to Android’s developer documentation, if a user denies a permission more than once, the system treats it as a permanent denial and stops showing the dialog. On iOS, Apple’s guidelines note that people review and change their choices later in the Settings app, outside your control. Each request is close to a one-shot chance, so wasting it on the first screen is costly. Apple’s Human Interface Guidelines advise waiting until people use a feature that needs access, and Android’s guidance says to ask in context when the user starts interacting with the feature.

How to do it

1. List every permission your app uses. For each one, write the feature that needs it and the benefit to the user. Remove any permission you cannot justify in one sentence.
2. Tie each request to a feature. Trigger the request when the user takes an action that needs it, such as tapping “Remind me”, “Scan receipt” or “Use my location”.
3. Explain the benefit in context. Show a short line in the feature itself before the system prompt: “Turn on reminders so we can tell you when your plant needs water.” Keep it specific and honest.
4. Follow each platform’s rules. Apple’s guidelines say a custom pre-alert screen should have one button, labelled something like “Continue”, that opens the system alert, with no option to close it. On Android, call shouldShowRequestPermissionRationale() and show an explanation when it returns true.
5. Write a clear system message. On iOS, the purpose string appears inside the alert. Write one active sentence that says what the app does with the access and why.
6. Plan for “no”. Keep the app working with a fallback, such as typing a city or adding a photo from the gallery. Never block the whole app because a permission was declined.
7. Offer a path back. In the feature’s settings, explain what the permission enables and link to the system settings page so users can change their mind.
8. Measure grant rates per prompt. Track how often each request is accepted and where it appears. Move or reword the weak ones.

Example

A hypothetical habit-tracking app used to request notification permission on the first screen, before users had created a habit. The team moves the request to the moment a user saves their first habit. The habit screen shows a toggle labelled “Remind me at 8:00 each morning.” Tapping it shows a single line of explanation and then the system prompt. Users who decline keep their habit and see a small note in the habit settings explaining how to turn reminders on later.

A second case: a hypothetical food delivery app stops asking for location at launch. The home screen shows a “Deliver to” field with two options: “Use my current location” and “Enter address”. Only users who tap the first option see the location prompt, and everyone else types their address.

Metrics to track

• Grant rate per permission. The share of users who accept each system prompt. Compare before and after moving or rewording the request.
• Permission-enabled share of active users. How many active users have each permission on. This is what matters for features like push reminders.
• Feature usage after granting. Whether users who grant access actually use the feature. Low usage means the request may not be worth the prompt.
• Retention by permission status. Compare retention for users with and without key permissions to understand what each one is worth.

When it backfires

• Fake system dialogs. Custom screens that imitate the system alert or use an “Allow” button can mislead users. Apple’s guidelines warn against both.
• Asking for too much. Requesting contacts, location and camera access for a simple utility app makes people suspicious and can lead to uninstalls.
• Pressure tactics. Offering rewards for granting tracking permission or blocking the app until users accept breaks Apple’s tracking rules and damages trust.
• Spammy notifications. Earning push permission and then sending daily promotions teaches users to turn notifications off or delete the app.

Questions people ask

Why not ask for all permissions on the first launch?

People have no reason to say yes yet, so many decline. On both iOS and Android, a declined system prompt is hard to show again, which means an early refusal can switch off a feature for good. Apple's guidelines also advise against asking at launch unless the app cannot work without the access.

Can my explanation screen have a "Not now" button?

Apple's design guidelines say a custom screen shown before the system alert should have a single button, such as "Continue", that opens the alert. If you want users to be able to skip, make the request part of an optional feature they choose to turn on.

What should I do when a user declines?

Keep the app usable. Offer a fallback, such as typing a postcode instead of sharing location, and explain in the feature's settings how to turn access on later.

Sources

• Privacy (Apple Human Interface Guidelines)
• Request runtime permissions (Android Developers)