How to Ask Users for App Permissions

Whether you are developing iOS or Android apps, you need to think about the best way to get your users to give you the permissions you need.

TL;DR: Getting app permissions right is critical — you often get one shot. Ask for permissions in context (when the user takes an action that needs it), not all at once on first launch. Be honest about why you need access and how the data will be used. Consider using a pre-permission screen in your app's own styling to explain the value before the native system prompt appears. Modern platforms like iOS and Android are giving users increasingly granular control (including partial photo access and mandatory notification opt-ins) so designing a respectful, transparent permission flow is more important than ever.

Why are app permissions important?

Does your iOS app need access to a user's location? Is the camera roll crucial for your core feature? Do you need to send notifications about new messages users receive?

No matter what access you need and whether you really need it (although I hope you do), you will need users' permission to access it.

Sounds easy, right?

The thing is, you basically have one shot to do it right. If a user says no, they can still change it in their settings. But they will do it only after seeing the reason to do it. If you don't do it right the first time, chances are, you may be losing your chance to show the value of your app.

The right way to do app permissions

It's really important to take a minute (a lot more, actually) to establish what the app really needs to run and give users the best possible experience.

If you're asking for permission that you can manage fine without, ask yourself the question, "do I really need this level of access at all?".

Whilst it would be nice to have free access to the whole device, just in case, if you ask users for permissions they don't understand, you will lose their trust — and trust is a huge issue with mobile apps. Our phones are extremely private, and we don't really like giving permission to access our information, it's obvious.

We are willing to give up some of our privacy only if there's a good reason behind it, but we have to understand this reason. Your job is to show users the benefits of giving you their permission and how it's going to be used.

You may think that users care only about the benefits. This (most common) narrative is somehow true, but it misses the mark: users are getting more aware, and yes, they do care about how their private information is going to be used. In fact, research from the Nielsen Norman Group confirms that clear communication about why a permission is needed and how data will be used significantly affects whether users grant access.

I can share examples of the most common questions users ask regarding their information:

• Why does this app want to know my location?

• Is it going to be shared somehow?

• Is it going to be used to sell me something?

• IS THIS SAFE?

So what should you do?

It's simple. Be honest. No need to explain technical details. Tell your users not only WHY the app needs location but also HOW it's going to use it.

How modern users and systems approach app permissions

Both iOS and Android have significantly tightened their permission models in recent years. If you're building apps today, you need to be aware of these changes:

On iOS, Apple's App Tracking Transparency (ATT) framework requires apps to explicitly ask users before tracking their activity across other companies' apps and websites. As of 2024, all App Store apps must also include a Privacy Manifest detailing data collection, SDK usage, and tracking behaviour. The latest updates require developers to disclose specific third-party data recipients rather than using vague language like "tracking for ads."

On Android, version 13 introduced a runtime notification permission (POST_NOTIFICATIONS), meaning apps can no longer send push notifications by default, users must explicitly opt in. Android 14 went further with partial photo and video access, allowing users to grant access to only selected images rather than their entire media library. Android 15 adds even stricter runtime checks when accessing content shared by other apps.

The takeaway: users now have more granular control than ever, and your permission strategy needs to respect that.

When and how to ask for app permissions

Just like with many mistakes from app developers, the most common mistake with asking for app permissions is bad timing.

When should you ask for it then? It's easy. When you need it.

Two popular approaches

If you read some articles on this subject, you will find 2 popular approaches to asking users for permissions.

• The upfront approach says it's best to ask for all you need when the user opens the app for the first time. More specifically, when the user is still in "installation mode".

Well... what if they don't open it for a few days after downloading it? This approach also assumes that users are used to getting permission requests, and that once they open a new app, they know they might have to click a few okays. These assumptions are correct. Users are used to it. But it's also extremely annoying. Personally, even though I expect it, I sometimes click "no" without even reading requests, just because I find it annoying and just want to get to the app running as fast as possible.

• The contextual approach — think simpler. Ask for permissions when it makes sense to the user.

You need access to the camera roll? Why would you need it any sooner than when the user wants to add an image from their camera roll? Microphone? You don't need permission to use it before your user needs to record something, do you?

Remember that asking for some permissions may seem a bit suspicious. Especially if you ask for something without referring to an action the user is trying to take. It may seem like it's going to interfere with the user's experience. Yet, if they try to take an action and see a pop-up. In this case, it may actually be a plus.

Since they already wanted to take this action and something gets in their way, they are more willing and motivated to read what it is all about and (as a result) understand what the app needs.

The contextual approach is now recommended by both Apple and Google as the default best practice. UX research consistently shows that user-triggered permission dialogs outperform upfront requests in acceptance rates.

The pre-permission screen (double request)

Another good practice you shouldn't overlook is the pre-permission screen, sometimes called a "double request" or "primer."

This involves showing an explanation of what you are about to request within your app flow, in your familiar app styling, before the native system dialog actually asks for permission.

Some experts will tell you to always show a pre-permission screen to have a chance to explain the purpose of the permission, but I can't fully agree with this. In some cases, it's great to communicate with users by showing them a nice explanation window implemented in your app.

This also gives you a chance to ask for app permission again if the user says no the first time. It's an option you don't have if you show a native request directly. Once a user denies a native system prompt, subsequent requests will simply not appear, and the user must go to Settings manually.

But here's the thing: not every request requires an explanation. Sometimes it just means forcing users to click twice and annoying them even more without a good reason.

There's no rule of thumb for that. You just have to adjust it to your application, keeping in mind that what really matters here is to make the app simple and enjoyable for end users. Appcues' research on permission priming offers solid strategies for when a primer adds value versus when it's unnecessary friction.

Handling denied permissions gracefully

One area that's often overlooked: what happens when a user says no?

Your app should always have a graceful fallback. Google's official guidelines recommend that you:

• Explain what's limited: Let the user know which features won't work without the permission.

• Don't block the whole app: If a permission is non-essential, let the user continue with reduced functionality.

• Offer a path back: If a critical permission was denied, provide a clear explanation and a direct link to the app's Settings page so the user can re-enable it.

Never repeatedly pester users who have already said no. Respect their decision and design around it.

Summary

Try not to be annoying. Don't force users to do anything. Respect them.

People really appreciate it when you're honest and respectful towards them, even in the application. Let the experience be as smooth as possible and try not to get in the way.

Go through your app, find what features need users' permissions, and figure out what is the best way of asking for them. You can be sure that if you put users first, they will love your app and share it with others.