This past June, Apple announced some changes that will affect how their Location Service works for their iOS 11 update. You might be asking why this so important.
To put it simply, Location Services has been a critical component for many apps, so any changes might have implications for the user experience and for app developers. That’s why Gimbal has put together this guide of iOS 11 Location Services best practices.
What is going to change with iOS 11?
Although there is a host of proposed changes, one in particular sticks out: how app publishers will be allowed to ask for the enabling of Location Services.
In iOS 10, applications could ask a user to enable Location Services in a single prompt showing two options. If a user selected Allow, then it was up to the application to set Location Services as Always or Never in the phone’s Settings.
The big difference in iOS11 is that any application that needs the Always location permission will be forced to offer users the additional option: While In Use.
If a developer wants (or needs) Location Services set to Always in order for their app to function properly, they have two options:
- The first is to show all options to the user in a single prompt: While In Use, Always, and Never
- The second option is to show the user a sequenced or phased approach.
I’ll go through each in a little more detail below…
The application has the choice of exactly when to show this single prompt.
The application has the choice of exactly when to show the sequenced approach, however, the order of prompts cannot be changed. You cannot show the second prompt before showing the first prompt.
The Best Approach
Applications should always gauge a user’s willingness and then prompt them accordingly in a way that is not intrusive to the user experience.
This is incredibly important because if a user declines Location Services, then the app developer won’t be allowed to ask the user to enable location services within the app ever again. This is especially problematic for companies that are reliant on location for the app to work.
Below is a user flow that illustrates how you can implement “gauging interest” to request Location Services permissions. This flow can be used for both new users or existing users.
Let’s dive in…
For new users, you should try to gauge the user’s interest in enabling Location Services using your own custom prompt. This can be seen in Steps A to B. Based on analytics from our other app partners, the opt-in rate for enabling Location Services during onboarding is higher than delaying and trying to ask them later.
Plus, everyone is accustomed to receiving these prompts when they open a new app and are therefore more likely to accept.
By showing a new user a custom prompt, you will be able to send them down one of the following user flows. Custom prompts also allow you to more explicitly highlight the value of enabling location services to your end-users over the less text and picture heavy OS-level prompt.
Gimbal has found that applications that highlight the benefit of location tracking during the custom prompt have higher opt-in rates than applications that do not present a custom prompt. The OS-level prompt should reiterate the benefit, as well.
User Tapped “Always Allow” in Custom Prompt B
If the user taps Always Allow in your custom prompt, then you can send them on their way down 1.0 and 1.1 and hope they select Always Allow in the OS’s prompt.
This is the ideal scenario.
Even if they decide to select While In Use, you would simply add them to the flow starting at 2.1. If they happen to select Don’t Allow, you will need to prompt them to change their settings like the Uber example below.
User Tapped “Maybe Later” in Custom Prompt B
If the user taps Maybe Later in your custom prompt, then send them to 3.1 and do not show them this prompt again until after both a time delay and a user action.
I will explain in the next example why this is important.
User Tapped “While In Use” in Custom Prompt B
If the user taps While In Use in your custom prompt, then you can show them the OS prompt with two options as seen in 2.1.
Many apps might stop here.
If your goal is to Always enable Location Services, you can prompt them after a specified amount of time has passed and/or after a user action (as seen in 2.2). As the app developer, you can decide what time frame and user action will trigger the prompt, but it’s important to keep in mind that you want this prompt to be within context.
For example, set a minimum time (say 10 days) and a user action like a main call to action that will trigger the prompt. By having the user trigger the prompt with their own action, they’re more likely to understand the value of location services in the context of the app’s functionality.
If the user continues to select Maybe Later as seen in 2.3 then simply send them back to the sequence starting at 2.2.
What Happens If They Selected “Don’t Allow?”
An app developer can still prompt the user to go into the app settings and enable Location Services using a custom prompt. However, getting a user to manually go back into settings and update this is unlikely and a tedious multi-step process.
Below is an example of how Uber prompts the user if they do not have Location Services enabled, but are still trying to use the app. This is why asking the user for Location Services at the right time is so important.
Clicking Turn On Location Services will take the user to settings
What’s important to remember is to try to enable Location Services at the right time. Even if the user keeps delaying their opt-in, Cluster showed that their opt-in increased from 30-40% to 46% when they asked users at a later (and better) time. If you try to prompt them too early or out of context, then you may lose your opportunity.
Context is key.
Interested in using Location Services in your app to trigger incredible user experiences?
This article originally appeared in The Mobile Majority.