The Right Way To Ask Users For iOS Permissions

Editor’s NoteBrenden Mulligan is a co-founder and designer at Cluster, a web and mobile app which enables users to create private social networks around interests and experiences. Brenden previously created and sold ArtistData and Onesheet.

Cluster is the first native mobile app I’ve designed, and the experience has taught me a lot about things to consider that aren’t necessarily a concern on the web. When creating a web app, you’re just building a page a user visits. But when creating a native experience, you’re not only asking them to download something but also probably asking them to give you access to their location or personal data. It’s a completely different relationship.

Because of this dynamic, we’ve spent significant time at Cluster on small interactions that increase users’ comfort and trust. One area we’ve focused on in particular is how we ask iOS users for access to things on their phone.

Our biggest takeaway: don’t ask a user for access until you really need it, and make sure it’s crystal clear what they will get in return.

Getting access the first time is critical

For many apps, not getting access to a phone’s sensors or data can change the entire user experience. For example, if an app depends on where the user is standing, declining access to location could render the app useless. More subtly, if push notifications play a critical role in getting your user to form a habit of using your app, declined access could lead to you losing them forever.

Making it all worse is that when a user taps “Don’t Allow”, there is no easy way for them to reverse that decision. It takes five steps to grant access later, and there’s no way to help a user navigate to the right screen besides actually listing the steps.

Turning permissions back on in an iOS app

Turning permissions back on in an iOS app

In other words, if the user denies access, the app won’t work properly — and it’s nearly impossible to explain how to fix it. This means developers need to do everything they can to get users to tap “Allow”.

The two most common approaches

There are two common methods we’ve seen apps use when asking permission.

1. The Initial Blitzkrieg (not recommended)

We’ve all seen it. You open the app for the first time and then “Can we send you push notifications?” and “Can we access your camera?” and then“Can we access your contacts?”

Unless the user is already familiar with the app  — WhatsApp probably doesn’t suffer from this problem, for example — they’re probably going to tap “Don’t Allow.” It’s like walking up to someone on the street and demanding they go on a date with you.

The first version of Cluster took this approach, and only about 30-40 percent of users accepted.

2. The Benefit Explanation (sub-optimal)

This method is significantly better than the Initial Blitzkrieg, but still not as effective as it could be.

HeyDay educating users why they should give permission.

HeyDay educating users why they should give permission.

Here, HeyDay tries to explain to a user the benefits they’ll receive by giving the app access. Then, when the user is educated enough, the app pops the question. Using this type of dynamic worked for us.

When educating the user about Cluster before asking for notifications access, acceptance increased from less than 40 percent to 66 percent.

The dynamics of certain apps may force them to only be able to use the above methods. If so, explaining to a user why access is important is so much better than just asking them for it.

How Cluster approaches this problem

Over time, we’ve learned to ask our users for permission when, and only when, we absolutely need it, and we think the user can clearly relate how this access will benefit them.

We’ve re-engineered Cluster using two methods to only show the system permissions dialog once a user has told us that they intend to say “Allow”.

Pre-permission dialogs

We’ve had a lot of success asking for permissions using our own UI before popping the iOS dialogs.

As stated above, the worst possible thing is for a user to deny permission at the system level, because reversing that decision in iOS is very complicated. But we ask them before the system does and they say no, we still have the opportunity to ask them again in the future when they are more likely to say yes.

For photos alone, 46 percent of people who denied access in a pre-permissions dialog ended up granting access when asked at a better time later.

This is simpler than you think. You can design your own dialogs, or use an additional iOS dialog for this.

Double System-Style Dialogs

In an older version of Cluster, when we asked for photo access, we would essentially ask them twice.

Using the iOS dialog for pre-permission.

Using the iOS dialog for pre-permission.

The first dialog (shown in the middle above) would set a local flag in the app that they’d said no, but it didn’t set it as “Deny” in the OS. That means if we want to ask them sometime in the future, we hadn’t burned our only chance.

Only 3 percent of users who clicked “Give Access” clicked “Don’t Allow,” meaning less than 2 percent of total users denied access at a system level.

Even though it seems annoying to ask twice, we almost completely eliminated the possibility of a user tapping “Don’t Allow,” leaving the door open for us to win them back in the future. And for what it’s worth, in live user tests, not a single test subject hesitated (or expressed confusion) when the second dialog appeared.

Educational pre-permission overlays

When asking for Contacts access, we wanted to do a little more educating, and the standard system dialog didn’t give us enough room or flexibility to fully explain what was going on, so we built our own that let us include an image.

A custom, educational pre-permission overlay.

A custom, educational pre-permission overlay.

So we first showed them a dialog about why we needed the access and gave them the choice to use the address book, or enter contact info manually themselves. And of course, we’d only show the system permission dialog if they specifically chose “Use Address Book.”

Like above, it was a bit of a pain to ask them twice, but when presented with the iOS dialog, no one ever hit “Don’t Allow.” Plus, when the people who tapped “I’ll Enter Contact Info” realized what a pain it was, we had another prompt that let them connect their address book at that point.

Using pre-permissions dialogs made the “Don’t Allow” problem almost disappear. It was exceptionally rare that a user didn’t give us access at a system level when asked. This was a major win for us. There was much rejoicing.

User-triggered dialogs (the most successful)

Even though users weren’t denying access at the system level, we were still getting our share of users who didn’t make it to the system dialog because they didn’t want to give us the access at all. What the pre-permission dialogs had done was mitigate the times where the user wasn’t expecting it, not necessarily making more users accept it. We knew we could do better.

When we deconstructed the problem, we realized that users still weren’t expecting to be asked, so we found a way for them to intentionally trigger the prompts, which in testing real flows with dozens of people has gotten permissions allowance close to 100 percent.


In previous versions, the first step in creating a new space in Cluster was to add photos. That meant we asked for photos access right after they hit “Create Cluster.” This resulted in the user granting photo access 67 percent of the time. But this could be improved.


We decided to move photo uploading back a few steps until they were a little more aware of what a Cluster was, and made them actually tap a camera icon and “Choose Photos” before we asked for access.

Asking users for photos access after they tapped a camera and “Choose Photos” increased the acceptance rate from 67 percent to 89 percent.

At this point, the user intended to upload a photo they’d previously taken, so giving the app access to their photos was a no-brainer.


We asked ourselves what the biggest user benefit was from granting contact access. It was similar to what we were getting at with the “I’ll Enter Contact Info” manually action in our pre-permissions dialog. But in that case, they hadn’t felt the pain yet, so the benefit wasn’t as clear.


Ultimately, we decided to let them see how empty the contact-adding process felt without the permission granted. Now, when they don’t see their friend show up in search, there is an action below that says “Show results from iPhone contacts.” Users generally tap this when they don’t see their friends in the list.

We found that since they are clearly trying to access their own address books, 100 percent of users accept the Contacts access when prompted.

Push Notifications

Cluster is used to build small private spaces with friends. We asked ourselves, what value would our users get out of push notifications? The answer was knowing when their friends were active in the space they’d created.


So when a user sets up a space for the first time and invites some people, we ask a very logical question: “Would you like to be notified when the friends you just invited join?” If they click “Notify Me,” we show them the standard iOS access dialog. If they say “No Thanks,” we let them move on.

During user testing, we saw a 100 percent success rate in iOS push notification permission after tapping “Notify Me.”

What we learned: context is critical

Clearly every app is different, but really thinking about when the user would naturally need access to different parts of their phone, and making sure they expect to be asked, has made a drastic improvement to the success of these system dialogs.

Huge thanks to Taylor Hughes and Riz Sattar from the Cluster team, who contributed a lot of ideas and data.