This article is part of a series about optimization and testing ideas for mobile apps.

Enabling users to take full advantage of all the features you’ve built into your app may require them to approve the app’s access to device features. During the onboarding process, test when you ask for these permissions.

You probably ask for a multitude of permissions, but do your users know why you’re asking for each one? And are there some that they’re more likely to respond to?

Asking for several permissions on during initial app load requires unnecessary taps and may make users weary of how the app will use their personal data. Introducing friction in onboarding may discourage users from completing the ultimate goal of onboarding: registration.

When to prompt the user

One of the biggest factors that determines whether users accept your requests is when they occur. If your new user experience begins with a slew of requests, you may be missing a critical opportunity to engage users and help them opt-in to your full-featured app.

Metrics to track: Acceptance rates, engagement rates

Idea #1: Test aligning permission requests with the obvious benefits of your app. Once users are engaged, they could be more likely to accept your requests.

Facebook Messenger asks for contact permissions when users would first want to sync their contacts.

Compare this with Snapchat, which doesn't start asking for permissions until much later in its tour, and includes this priming message, clearly explaining why it needs your permissions and what it won't do with them.

Idea #2: Test "pushing" requests vs. "pulling" for them. Test prompting users to accept permissions only when they try to use a specific feature. This way, your permission requests will be more contextual and intuitive.

Cluster decided to have the user trigger requests for features. When the user taps a feature like the camera, that triggers the request for photo permissions.

Idea #3: Test asking for all permissions at once vs. asking for different permissions progressively.

Skype Qik explains why it needs all of the user's permissions at once.

Priming before the request

You can only trigger Apple's default permission request once per feature, so some apps “prime” their users to accept requests before the actual Apple permission request screen appears. This is a prime opportunity to test how to best prepare your user to accept permissions.

Metrics to track:

  • Acceptance rates
  • Engagement rates

Idea #1: If you're not priming your users at all, test including "primer" messages before the Apple request screen appears. See how the inclusion of a primer screen affects user behavior.

Inbox by Gmail asks for permissions before beginning its onboarding tour, with no additional context. Could it increase acceptance and engagement by providing a primer?

Compare this to Cluster's flow, which includes a context-building screen, a primer, and then finally the permission request.


Idea #2: If you already have primers, test the copy and style to see what works best. Try copy that makes your user feel at ease vs. copy that drives at the value that the user will get from accepting the request on the next screen. 

Instagram uses a primer almost identical to the Apple default, providing maximum context for why it needs all permissions.

Rooms uses a pop-up style similar to the Apple default for its primer, with minimal context for why the user should accept. It also provides the option in its primer to save the permissions prompt for later.

Cluster used to use a permissions dialog similar to Apple's, but ended up building their own version that includes an image and some copy explaining the value of accepting the permission.

Idea #3: Test the rationale you give for your permission requests. Users may respond to different reasons that you need them to give your app permission.

Foursquare uses FOMO (fear of missing out) as a way to ask users to accept notifications.

Grouper asks for Contacts permissions by using invites as a way to move up in its waitlist.

You may also try handling objections preemptively. For example, when asking for push notification permissions, you could say, "We promise not to bother you." Will that instill confidence, or will that put the idea in their minds that your app is bothersome? For example, how does Snapchat's primer make you feel when it mentions spam?

Idea #4: Test priming during the request. You can do this by providing a background image that contextualizes the permission request.

Foursquare primes users as the Apple default pop-up is on-screen, by providing a background image that explains why the app needs that particular feature.

Prompt for re-notification

If users don’t accept your permissions the first time, test how you prompt them to notify you when they need to accept permissions again.

Metrics to track:

  • Acceptance rate
  • Engagement rate
  • Acceptance rate for users who have initially declined

Idea #1: Test including re-notifications in your settings. Some apps make it so difficult to re-activate notifications that once users click "Don't Allow," they'll never be able to activate those features easily. For instance, this is a sample user workflow to reactivate permissions:

Idea #2: Test the copy of your re-notification prompt. What might be persuasive to users who didn’t accept your permissions, and help them understand why and how they should reconsider?

Idea #3: Test re-notification prompts that focus on why accepting permissions is beneficial, vs. how to access the permission requests in the future. Do you think your users aren't re-signing up for permissions because they don't see the value, or because they don't know how to do it? Test this hypothesis through re-notification request copy.

How to set up a permission request test in Optimizely

With the Visual Editor:

In Optimizely's Visual Editor, you can test a number of different ideas from this article, including making copy changes to your notification primers and re-notification requests, swapping the background image used during the permission request, and making layout changes.

With Code Blocks and Live Variables:


In this section, we provide templated code, which you can use for guidance as you’re thinking about how you would like to implement code blocks with Optimizely.

Using Live Variables, you can test when to ask someone for permissions for push notifications. The code might look something like this:

OptimizelyVariableKeyForNumber(showNotificationVar, @(3));

NSNumber *whenToShowAlert = [Optimizely numberForKey:showNotificationVar];
if ([numberOfTimeScreenAppeared intValue] == [whenToShowAlert intValue]) {
    // Call method asking for permissions

With Code Blocks, you can add a layover for your "primer" request before the default Apple alert. You can A/B test the alert you want to show to get people to change their notification settings. 


If you use code blocks to insert the major features you want in your new onboarding, you can use the Visual Editor from there to make copy, color, and layout changes for views that have been added via code blocks. In order to make visual changes to those code blocks, simply select the code block that you want to show in your variation in the drop down, and then switch back to the Visual Editor to make the visual changes in your code block.


Depending on which permissions alert you're trying to test, you can target users based on whether notifications are enabled or not.


When you test permissions requests, you'll want to see if the number of people that have enabled notifications has increased. A great way to do this is to track a custom event (iOS | Android) in the alert view. Remember that users will always start out in a state where notifications are not enabled.