iOS 13 Location Permissions

Location Permissions have changed for the better in iOS 13. More weight has been put behind the user’s privacy.
Not only has Apple added a new permission type “Allow Once” but also they’ve changed the way “Always Allow” permission used to work.

What’s Changed In CoreLocation?

With the release of iOS 13, CoreLocation framework has changed. Now, you’ll see a different kind of permission dialog for location permission. It has new permission “Allow Once”.

The following illustration shows the permission model change from iOS 12 to iOS 13.

ios-13-new-permission-vs-old

CoreLocation Permission Authorisation

In order to show location permissions we can need to configure the CLLocationManager instance in either of the two ways:

  • requestAlwaysAuthorization
  • requestWhenInUseAuthorization

iOS 13 requires adding the following two privacy usage descriptions in the info.plist file:

  • NSLocationWhenInUseUsageDescription
  • NSLocationAlwaysAndWhenInUseUsageDescription

Changes In Permission

iOS 13 has the following three location permissions(ignore denied since it ignores the permission!):

  • Allow While In Use – Has superpowers of Allowed
  • Allow Once – Temporary “Allow While In Use”
  • Allowed – Deferred until really needed.

Among these, Allow Once is the new one so let’s start with it!

Allow Once Permission

Allow Once is similar to Allow While Using, but only for one foreground session. That means that once you leave the application for a considerable time, the permission state changes to notDetermined.

The next time the user starts the application the developer can ask for the permissions again depending on their use case. This gives users some finer control over the location data and also allows the developers to handler one-off location cases easily.

Allow While Using Permission Defers Always Allow

Always Allow permission isn’t there by default in the new permission dialog. It’s there in a provisional form so that it can be used when it’s actually required.
Let’s see how that works with two authorization scenarios

  • Case 1: requestAlwaysAuthorization
    Allow While Using Permission handles Allows Allow permission only if you’ve requested location authorization using locationManager.requestAlwaysAuthorization().

    With the above type of authorization, the user sees it as foreground permission but CoreLocation informs the Delegate that it’s always permission. This way, it can monitor location events in the background but the CoreLocationManagerDelegate cannot receive those events.

    CoreLocation holds onto the events and asks the user an appropriate time whether they would like to Allow Always?. After that, the location events can be received in the background as well.

    This way, Always Allow is deferred until a stage where it really requires user permission.
    The above case makes Always Allow a provisional authorization.

  • Case 2: requestWhenInUseAuthorization – In this case, Always Allowed never happens, since the developer themselves haven’t asked for it. Location is only accessed when the application is in the foreground(though it continues to access it for a very short interval once the user switches to the background).

Here’s a flow of both the cases and what happens under the hood:

ios-13-location-permission-model-flow

Conclusion

So the new permission model is much simpler since it hides the Always Allowed Option from the prompt and makes it a part of the While Using Permission. For “Always Allow”, it asks for the user’s consent only after you’ve tried to track them in the background.
This way, it strives to provide clarity and transparency to the user about the permission requirements.
It

That sums up this article. Here’s an example of MapKit and CoreLocation with the new iOS 13 Location Permissions.

Leave a Reply

Your email address will not be published. Required fields are marked *