The Right Way To Ask Users For iOS Permissions

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.

Double System-Style Dialogs

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

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.

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.

Photos

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.

Contacts

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.”