WWDC 2017 Update: Significant Updates to Location Permissions Coming With iOS 11
With WWDC 2019 and iOS 13, see the latest information here regarding location permissions.
At WWDC today, Apple provided some updates that have significant implications for developers and app publishers working with location-based marketing and attribution. These changes fundamentally alter the way iOS developers and app publishers will be able to access differing levels of location permissions for their mobile apps.
Until these recent updates (which will be coming with iOS 11 in September 2017), app publishers had the option of requesting a user to opt-in to location permissions as ‘always’, where the app publisher always has access to a user’s location or ‘when in use’, where an app publisher only has visibility to a user’s location when the app is open, or running in the foreground. Developers could choose which permission set they wanted to request and were not obligated to offer both.
This meant that publishers could effectively force users into granting ‘always’ permissions by not providing the option of ‘when in use’, rendering apps that rely on location (Uber, Lyft) effectively useless without the ‘always’ permission level.
In addition to the Uber-style use case, ‘always on’ permissions are a requisite to delivering beacon and geo-fence based push notifications. These types of notifications essentially ‘wake’ a sleeping app when it is in the background, prompting the user to open the app with a notification when they come in range of a beacon, or enter a geofence that the app is monitoring for in the background. Without the ‘always on’ permission level, location-based notifications aren’t possible.
What’s Coming With iOS 11
If you request ‘always on’ with these new location-permission rules, users will automatically be given all three options when they open an app requesting location for the first time. Unlike in previous iOS versions where developers could choose which permissions they wanted to request, all options must appear. These mandatory location permission options are: Never, When in Use, and Always. This forces app publishers in to providing users with all choices, rather than just the always-or-nothing scenario described above.
You’ll also notice that the option for When in Use is placed as the first option. It is clear that with this update Apple is pushing developers in the direction of only asking for the ‘when in use’ permission set.
A New Two-phased Approach for Location-permissions
For those seeking always permission levels, Apple is now recommending a new permission flow which is essentially a two-phased approach. The first phase or initial onboarding, should only ask for ‘when in use’ permissions. After the user has engaged with your app and better understands the value and use cases provided to them with location tracking, trust has been earned and publishers can present users the option to ‘upgrade’ and request the ‘always’ permission level.
Apps that choose not to opt-in to this approach and immediately ask for ‘always’, will not have the option later to try the two phased approach. One would expect that the result will be a decline in opt-ins and the window of opportunity for obtaining permission will be missed.
What are the Implications
In order for app publishers to continue to engage users with beacon and geo-based push, as well as capture valuable location and attribution data, mobile developers and UX designers will need to revisit their approach to garnering location permissions. For those app publishers looking to achieve the ‘always’ status of location opt-ins, success will likely require the approach described above. The benefit of this approach is that when presented with this follow-up messaging asking further access, users may deny this ‘always’ permission request but won’t be presented with the dreaded ‘never’ option in this follow up scenario.
Having spent a good deal of time refining best practices for location onboarding and location-permission tactics, we think publishers will need to think seriously about this two-phased approach which seeks to get to the ‘always’ status more incrementally, by starting with the ‘when in use’ permission set.
Recent research from the Rover team highlights some of the average location permission opt in rates app publishers can expect to see from their users but, it is very likely that these updates will have an effect on the iOS opt-in rates we’ve seen over the last year.
