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.
Jump to a section:
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.
App permissions — do it right
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. But 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 gonna 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.
(I wrote about the importance of understanding the users and how it affects ratings in a separate blog post).
As a Product Development Team Leader, having run multiple users' tests and surveys, 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 gonna use it.
Compare the information users receive in the 3 examples below:
Google Maps Location Permission
Uber Location Permission
Heyday Photos and Location permissions
When and how to ask for app permission?
Just like with many mistakes from app developers, the most common mistake with asking for app permissions is bad timing.
When you should 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 first 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 to get to the app running as fast as possible.
- The second approach is - 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 user is trying to take. It may seem like it’s going to interfere with 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.
- Another good practice you shouldn’t overlook is the double request.
The double request involves showing an explanation of what you are about to request within your app flow, in your familiar app styling, before the native control actually asks for permission.
Some experts will tell you to always show a double request 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 will also give 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.
But here's a 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.
Cluster App Push Notification Permission
I will repeat it again and again — 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 a 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.