Adapting to new location permissions for iOS 13 [DEV GUIDE]

Apple has released two major changes to the way location permissions work in iOS 13. Here, we offer guidance on how to avoid losing users over these new location permission optimizations. 

The two changes, in short:

1. 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.
2. The second change gives users more insight into the location data that was collected by your app. In this verions of iOS, users are required to give consent for tracking their location while your app is in the background. After some time, users are presented with a summary of locations tracked by the app.

When will these changes take effect?

Both of these changes are immediately applied to all apps when the user upgrades to iOS13, even if you as a developer don’t touch your app. No code changes are required to support these new location permission flows. It’s good practice to know how it works, so you can keep as many users opted in to your location services as possible. 

When you request location permission from the user through CLLocationManager, they will see the following three choices in the form of a pop-up:

1. Share the location just once with the app and ask again

How the ‘allow once’ permission works: Your app will be notified that the CLAuthorizationStatus changed to authorizedWhenInUse. This is just the same as in the older iOS version when you get permanent permission. Your app is now allowed 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.

3. Share the location with the app when the app is in use

 How ‘only when in use’ permission works: Getting consent to track background location has become slightly more difficult, but in exchange, your users will enjoy more transparency about where their device – i.e. they – have been. 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 from what we’re used to in previous iOS versions: before, the user was allowed to give the “always” permission directly at the request. When it comes to code, 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 a while of tracking their location, iOS will periodically make sure it still has the user’s consent. In this new permission opt-in flow, the 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.

3. Don’t share location with the app at all 

The introduction of this dialog is a call for apps to consider how, when and why location is being tracked in the background. Tracking at unnecessary moments will mean that users don’t understand its value, and might revoke permission completely with the arrival of this location opt-in dialog.

Although there are no code changes required, it’s advisable to conduct a review to check you’re requesting to track location only when the value is clear for the user.