Adapting to the new 'allow just once' location permission in iOS 13
At the WWDC19 keynote Apple announced two changes in the way location permissions will work in iOS 13. Avoid losing users over these permission optimizations by understanding these changes.
Avoid losing users over Apple’s new location permission optimizations
At the WWDC19 keynote Apple announced two changes in the way location permissions will work in iOS 13. The first change gives users the option to share their location with your app just once. This makes it easier to try out location features and helps users keep sensitive location data private.
The second change gives users more insight into the location data that was collected by apps that have access to location data in the background. In the new version of iOS, users are required to give consent for tracking their location while your app is in the background. After the app has tracked locations for some time, users are presented with a little report about which locations were tracked by the app.
Note that both of these changes are immediately applied to all apps when the user upgrades to the newly announced iOS version, even if you as a developer don’t touch your app. No code changes are required to support these new location optimizations. Still, it is good to know a bit more about how it works. After all, you want as many users to opt-in to your location request as possible.
How the ‘allow once’ permission works with existing apps
When you request location permission trough CLLocationManager
, the user will see this popup with three choices:
- Share the location just once with the app and ask again
- Share the location with the app when the app is in use
- Don’t share location with the app at all
If the user taps option 1: “Allow once”, your app will be notified that the CLAuthorizationStatus
changed to authorizedWhenInUse
. Just like you’re used to in older iOS version when you get a permanent permission. It is now allowed for your app to start requesting locations, no code changes necessary.
Users can jump out and back into your app, and you will still have location permission. It’s only after a (longer) period of inactivity that iOS will revoke the permission and turn the CLAuthorizationStatus
back to notDetermined
. Your CLLocationManagerDelegate
will get notified of the change in location permission when the app is back in the foreground so the UI can be updated accordingly.
This makes the new ‘allow once’ feature a nice privacy improvement for your users. It also lowers the bar for users to give location features in your app a try and decide later to grant a more permanent permission.
Background location shows the user what you’re tracking
Getting consent to scan for location in the background has gotten a bit harder but in exchange, your users will enjoy more transparency regarding the locations you’ve received in iOS 13. The first notable change is that even when you call `requestAlwaysAuthorization`, the user will only get the ‘just now’ and ‘when in use’ options in the permission dialog. If the user grants you ‘when in use’ permission and you try to scan for location in the background, only then the user will be presented a dialog to grant the background permission.
This is different to what we’re used to in older iOS versions where the user was allowed to give the “always”-permission directly at the request. On a code level, the only difference will be in the moment you receive the permission. If you make sure not to base the value of `allowsBackgroundLocationUpdates` on whether or not you have background permission, the second permission dialog will never change.
After your app has been tracking the user’s location in the background for a while, iOS will make sure it still has the user’s consent. In this new iOS version this consent renewal dialog will include a small report with the locations your app has been tracking. This makes it more transparent to the user what is happening in the background.
Note that I couldn’t test this fully with our Rijksmuseum app since beta 1 crashes on me as soon as I set the allowsBackgroundLocationUpdates
property on CLLocationManager
to true
. Please also file a radar for this so Apple can go and fix this.
More privacy & transparency for free
As app developers, this should make us even more aware of when we’re tracking location in the background. Tracking it at unnecessary moments will mean that the users will see that in the report and might revoke the permission. So while there are no code changes required, this might be a good moment to review your location code to check whether you’re only requesting it when valuable for the user. Doing this before iOS 13 is publically available will make sure that users don’t feel like you’re abusing their consent for tracking their location in the background. In the end, it might prevent disgruntled users from uninstalling your app. Remember that in this beta it seems that even apps currently in the AppStore will be subject to these changes, no recompilation necessary!
I feel this is a very nice privacy and transparency update for the user, and Apple made full use of their neatly designed API. It is a schoolbook example of good API design where the implementation is improved without the consumers needing to be aware. I think we all can learn from that.
Check out our other WWDC19 blog posts on https://engineering.q42.nl/tag/wwdc.