It’s a smart move from Google and Apple to let users decide which permissions they want to allow or revoke. This in mind, it’s a good idea that you as an app maker think of building attractive in-app permissions. Permission requests are there to protect sensitive information that is on the device. Permission requests should be used to only access information necessary for the functioning of the app.
How apps ask for permissions differs from app to app. But the challenge for iOS app makers is that iOS gives you the ability to ask for a permission only once. So you have to get creative. Otherwise, the user should go find out how to turn the permission back on in OS settings. So, let’s now look at a few scenarios of in-app permission requests and see which of them are bright and which ones are total disasters.
1. Asking right away
Some apps ask for in-app permissions right away as soon as the onboarding is completed. This is, of course, the easiest thing to do. But at the same time, it’s the hardest to recover from. Because if you waste the chance of asking again, then you might not get it back anymore. For some apps, it’s strategically important to ask for certain types of permissions right at the beginning. For example, Tinder asks its users whether it can access their location or not since its recommendations are based on the user’s location.
But we have got mixed feelings about this kind of in-app permission requests. While some people might be excited and might actually allow the app to access their location, others might simply turn down the annoying message without even reading it properly. So you might be risking it. And it’s just 50/50.
2. Asking twice
Yes, we have already said that you can only ask for an in-app permission once but that does not mean that you cannot play a little dirty game by first asking one preparatory question to the user. It’s like letting the user know that you might be asking them for a permission to access information. Polite, right? Take a look at the below example:
The first request is not the actual in-app permission request. It serves as a simulation. The second one is the real OS prompt. But the user sees it only after agreeing in the first message. Doing this can provide 2 benefits:
- If the user denies the first in-app permission request, the app can still show them the real OS prompt later on, after considering a better timing.
- The first message can teach about the importance of giving in-app permissions and the user might be more eager to granting access at the second time.
3. Asking as soon as the user takes an action
Another thing you can do is to wait until the user comes to the point where they have to take an action themselves. For example, they click to upload a photo and you ask for a permission to access their Gallery. This approach is as simple as pie! And the good thing here is that since the app is asking for a permission in a certain context, the user is less likely to deny it.
Bonus tip
Whenever you are asking for an in-app permission, make sure you provide enough context and you focus on the value proposition. In the end, you are asking for a permission to provide your users with something useful, so make sure you are describing your actions in an informative and understandable way. Look at the examples below:
At the end
Overall, avoid requesting unnecessary permissions. Don’t ask for sensitive data such as the phone’s IMEI number. Do not request to take a full control over the Wi-Fi or data connection. This is unethical!
Also, remember that every time you ask for a permission, you force the user to take action, to make a decision, to do something that they were not thinking of doing. Hence, make sure to minimize the number of times you ask for in-app permissions. You don’t want to distract your users and to eventually bore them, right? Think about it!
