5 Ways Apps Ask Users for iOS Permissions (Product Breakdown)
and what to do if the user denies
Product Breakdown analyzes different products every week and lists noteworthy product and UX learnings. We believe that the best way to master good product practices is to learn from others.
Intro
We’re taking a departure from our usual app-a-week model to delve deep into one specific area — how apps ask for permissions. From the beginning, iOS apps have asked users for permissions when the app runs (and not during install). Android is moving to this model as well starting with version M.
The challenge here is that iOS only gives you the ability to ask for a permission once — if the user denies the request, they must now go deep into the OS settings to turn the permission back on. As a result of this, apps have gotten very creative about how they ask users for permissions.
1. Just Ask and Pray
A number of apps asks for permissions right off the bat. Easiest to do, but hardest to recover from if the user denies, as you lose the ability to ask again.
Some apps go further and hit you with a series of requests on first launch (Allow camera access? Location? Notifications?). While this can work if the user is already familiar with the app, there is the risk of the user getting trigger happy and turning them down.
2. Nudge the User
This is similar to the “just ask” approach, but these apps try to give the user a little nudge on what to click on. Check out how Lyft does this:
3. Ask Twice — and Prepare the User
A common workaround to the issue of only being able to ask for permissions once, is for apps to show a “fake” request before the real one.
The first request is actually a custom app UI — the user is shown the real OS prompt only when they agree in the custom UI. This has two advantages:
- If the user denies the first in-app request, the app has not blown its chance to show the real prompt, and can ask the user again at a more opportune time.
- The in-app UI can also show some education on why the user should give permissions.
This works as users are unlikely to give permissions initially and then reject it when asked again by the OS prompt. See how Shazam does this below:
4. Wait for a User Action
Another common approach is to wait until the user takes the relevant action before asking for permissions. The advantage here is that since the app is asking in-context, users are more likely to accept. For example, an app may ask for location when the user taps on the “current location” button, or ask for camera permission when the user tries to take a photo. See examples from Layout and Cluster below (Cluster wrote about their experience a year ago).
5. The Checklist
If an app needs multiple permissions at one time, one way to encourage users to give all of them is to show them as a task “checklist”. Periscope does this when the user tries to broadcast their video for the first time.
What if the User Denies a Permission?
If the user denies a required permission, some apps simply tell you to go find the right place in iOS Settings to turn permission back on. This is often sub-optimal as the user then has to go through a 5 step process to do so. Check out the process from Vine below:
Recently, starting with iOS 8, many apps have started to deep-link users to the correct place in Settings. See what Shazam does if the user does not give access to the microphone:
While this is still not as ideal as being able to simply ask the user for permission again, it drastically cuts down on the number of steps the user needs to follow.
If you liked this article, you can read more Product Breakdown articles here.
