Apple showcased a lot of major changes in WWDC19, with SwiftUI creating a lot of buzz among the developers. But there were also some other changes that are important and will be affecting the user experience right now. One of them is the updates in the Core Location framework.

iOS 13 improves user privacy related to location sharing. If your app needs the location of the user to recommend or display content, you may need to investigate if your app is still running properly.

Starting from iOS 13, users will be getting a new option to share their location just once. They’ve also empowered While in Use permission and changed many other things. Assuming that you have already worked with Core Location before, let’s discuss the updates in detail.

Updated Location Permissions Prompt:

With iOS 13, Apple has updated the authorization request prompt, giving more powers to While in Use authorization and adding a new type of authorization called the Temporary Authorization.

As seen in the image, the Location accessing request prompt now has three options: Allow While in Use, Allow Once and Don’t Allow. We won’t be discussing the last option as that is quite self-explanatory.

Note: This request prompt will be coming only once, so it is recommended to request for the location services where it is understandable for the user as to why you need the location services.

Case 1: When Always Authorization is requested:

If an app requested for Always Authorization, the same prompt will be shown to the user. But as you would have noticed, this prompt doesn’t have any option for providing Always Authorization to the app. So how would the user be providing Always Authorization?

What will happen here is, whatever the user chose, the OS will remember it. Let’s say the user selected the most positive option among the three, i.e., Allow While in Use. While the app will get While in Use authorization, it will also enter a Provisional Always Authorization zone.

So, what is Provisional Always Authorization? Well, in simple terms, for the user, the app is having While in Use location permission, and the same can be seen in settings as well, but for the app, it is having Always location permission. And will perform its executions accordingly.

This brings up a question. Until when will the app be enjoying the Always authorization in such cases?

Let’s say the app requested Always authorization to monitor location events in the background. The app being in Provisional Always authorization, will monitor events both in the background and foreground state. But on receiving any event, it won’t be sent directly to your CLLocationManagerDelegate. Instead, Core Location will hold onto the events and ask the user at an appropriate time whether they would like to upgrade the app’s location services access permission to Always authorization. The chosen option will decide whether the app will receive the event or not.

The received event will be delivered if the user chose Always Authorization, else it will be

  • Not delivered until chosen
  • Dropped if chosen to keep using While in Use
  • Replaced by a new event (this might occur because the prompt isn’t directly shown, but is delayed until the user is not busy so that it understands what is asked)
  • Dropped if got stale

Case 2: When While in Use authorization is requested:

While in Use authorization will work the same way as expected, opening the same permission prompt and getting While in Use if the user selected that.

Empowering of While in Use authorization:

The application can either request for Always or While in Use authorization. But how should one be making such a choice?

As till iOS 12, these were the main differences that led one to decide whether to ask for Always location permission or not.

You will notice that the services/apis not available for While in Use permissions, like Region Monitoring, can deliver events both when the app is in use or not if Always location permission is provided by the user. But if While in Use authorization is provided, none of the events are provided, not even while the app is in use.

So, with iOS 13, the focus of separation has been changed and made to be more focussed on whether the app is in use or not. This will also help an app to not unnecessarily request Always location permission if they only intend to use the location services when in use.

But this brings up another question: At what all times is my app is being considered to be in use by the OS?

Well, the answer to this question breaks up into two different situations:

  • When not using background location updates: Here, the app will be considered in use until it is in foreground and till the few seconds before going background state. As soon as the app again enters the foreground, location services will start for the app.

  • When using background location updates: Here, the app will be considered in use until and unless the background location updates are enabled. Once it gets disabled, it will become the same case as above.

Temporary Authorization in iOS 13:

One option in the location request prompt is left to discuss, that is Allow once. This, as one might guess, will be just for one App-In-Use session of the app. Let’s discuss what happens under the hood.

Earlier, in iOS 12 or before, Not Determined authorization state basically was that the user has not yet determined whether to provide access or not. And on showing the Location permission prompt, the user will decide and it could either be While in Use or Always authorization.

Now also it will be the same, just that when the user chooses Allow once, the app will enter in temporary authorization state, where it will be receiving While in Use authorization. The app will execute as if it is being granted While in Use authorization. But in reality, its authorization state would have been not determined.

The app will be in this state until it is in use. So, as soon as the app is not in use, it’s permission will be reverted back to be Not Determined.

Note: The rules for an app being in use for temporary authorization are the same as those discussed in the previous section. So as one might guess, the app would need to request again for location services once the app goes in background, when not using background location updates.

Conclusion

This is the updated overflow for the Core Location authorization flow after the iOS 13 updates:

Hence, with these new improvements to the Core Location framework, Apple has really thought about the user’s location privacy and to why one should grant location permission to the app. These improvements also make it important for the app developers to ask for the location services where it makes sense for the user to provide one the permission, with a good description of what you want to do with the location permission.

Share this:

Privacy Preference Center