What's new in location

Hello and welcome to WWDC.

Hello there. I'm Ilya Veygman. I'm a software engineer with Core Location.

Today I'll be telling you about all the cool new stuff in Core Location this year. We will be primarily covering Location Authorization. And we will also discuss some new features from this year's release, App Clips and Widgets.

Let's start with Location Authorization.

I want to begin by talking about the state of the world in iOS 13. As of the most recent major release there are basically three ways a user can control the circumstances under which an app can access their location.

A user can respond to a location prompt or go to Settings and set one of these options. Which means that an app can get their location information at no time. Only while it's in use, or at anytime. As user privacy is and has been a major priority for Apple we thought: are there any other controls we can give the user which will allow them to regulate access to their sensitive location data? To do so we ask ourselves this question - What does this app really need to know about me in order to do its job? A privacy conscious user is likely to ask themselves the same question. And one way the user will ask this is not just is this app getting my location when I don't want it to. They will also ask whether the app needs to know exactly where they are as opposed to approximately where they are. There are certain classes of apps where a user may not see the need to give their exact location and will be satisfied with the app knowing just approximately where they are.

Does this dating app for example, really need to know anything other than my town. Does this local events app have to know what hotel I'm staying in.

Does a social media app need to know exactly where I've been. In fact they might prefer to give only minimal information and nothing more. There are certainly use cases where exact location is preferred if not necessary.

For example if you want to use a navigation app to get turn by turn directions from wherever you may be to your destination you would need the app to know exactly where you are. But there are other classes of apps where sharing just a little bit of location information makes sense for the apps expected functionality. In the case of a dating app or a local events app for example, it's certainly possible to make hyper- targeted recommendations or matches to a user if you have their exact location. And this is a great feature for some, but others may not be interested in that level of detail and would prefer to not share location at all rather than to access that functionality.

In cases like these approximate location might in fact be good enough for many users. In iOS 13 a user getting an initial prompt for location authorization would see something like this. Starting in iOS 14, and as you saw in the keynote a new option will appear in the prompts for users - Precise. This option lets the user grant an app only their approximate rather than their exact location. This will also be visible to users under Settings. By disabling the precise location switch, the user can choose to grant only approximate location to the app. As a result of this the user now has two dimensions upon which to specify how much location access they would like to grant an app. There is the "what circumstances" of an app accessing location and there is now also the "how much" dimension of location access. Now instead of just the one notion of location authorization we have two. Users can do all sorts of things with authorization now. Initially grant while using with reduced accuracy, upgrade it to the full accuracy and even do things like change the authorization to "always" and then downgrade the accuracy to "reduced" again.

Now, one thing that should be made very clear before we continue. Apps cannot opt out of this new feature. This functionality is controlled entirely by the user. It's another form of authorization after all, and the user decides whether they grant or revoke authorization at any time. You, the app must adapt to this new world where you just can decide not to give the app exact location information at all times. Given that, I think it's time to talk about the tools we're providing you to adopt this new feature.

First we're deprecating the CLLocationManager class method for authorization status and replacing it with a property that delivers the app's authorization status just like before. We also introduced a new instance property that indicates how accurately the app can know user location. There are two options for this enum, full and reduced. Full is a sort of default from the pre-iOS 14 world, while reduced is the new scenario. To further accommodate these new notions of location authorization. We're further changing up the authorization status delegate callback. We're deprecating the old DidChangeAuthorization status callback and replacing it with a new locationManagerDidChangeAuthorization callback method. This new method is invoked whenever either the authorizationStatus or accuracyAuthorization property values change.

Here's how you might want to implement the new delegate callback method. You will need to check the values of both the authorization status and the accuracy to determine how to proceed. Now, a few notes on how these are delivered. Reduced accuracy fixes are still delivered to the didUpdateLocations delegate just like before. And they're still expressed as CLLocation objects with a CLLocationCoordinate2D center points and a large value for horizontal accuracy. These locations are recomputed about four times per hour. So if you have some timeout logic in the application you should make sure to inform it using the value of accuracyAuthorization.

Finally while these are represented as CLLocation objects you should not treat them like you would a typical location with full accuracy.

Instead you should consider them to contain the user's true position. Now, let's have a look at a case study of a top notch adoption of this new feature in maps. The Maps team have worked closely with ours to bring you what you can see in iOS 14. And have done an amazing job of adopting the new Accuracy Authorization API. Please check out their talk on Designing for Location Privacy which will cover some topics that are very relevant to what we'll discuss here. New in iOS 14 when Maps, or any app asks for location for the first time they would see this prompt. Just like you saw before which will show an inset map with your location on it. Let's toggle the "Precise: On" pill to see what happens. This will show you what the underlying app would get if you gave it full versus reduced accuracy.

This will be immediately obvious by seeing the big circle indicating the user's approximate location in the app rather than the familiar blue dot.

Let's see how this looks when you grant authorization to the app and launch it.

As you'd expect, the UI will show a large circle indicating the user's approximate location rather than the blue dot that you're probably used to. Again this circle contains the user's true position and now Maps also does a really good thing here by placing a banner at the top of the UI which clearly indicates to the user that they have reduced accuracy for this app. This is a good thing to consider when you're designing your own app to adopt this feature. How to reflect this reduced accuracy and authorization back to the user. Now, looking at where we are isn't the only thing we use Maps for.

We also like to use it to navigate to places. I'm going to look up directions to my favorite museum after work. Swipe up here. Tap on California Academy of Sciences. And OK we see something new here. Maps is informing us that getting directions from where I am to the museum needs my exact location with full accuracy. If you have a feature that needs exact location but you don't have full accuracy authorized, what do you do? So let's pause and talk about that. What do you the developer, do if the user is only sharing approximate location with your app which you have a feature that needs exact location. Well you've got two options here. First you can send the user to Settings and ask them to upgrade you to full accuracy permanently.

This may not be attractive to all users and some might prefer to simply not use that feature or even stop using your app entirely, rather than grant you more access than they want. Fortunately the other option is far more attractive for these kinds of users - temporarily granting full accuracy.

Here's how you would do that. We have a new method on CLLocationManager that allows you to prompt the user for temporary full accuracy. In this example the user is prompted to upgrade their location accuracy authorization.

If they do not have full accuracy. After they respond this completion block is called which calls start navigation if we got the renewed response.

Now we must set a purpose key when requesting this temporary accuracy authorization upgrade.

This is a very important point to remember. You have to explain to the user why you need this upgrade and this purpose key will show them what that reason is. So let's talk about how to specify these. To ask for temporary full accuracy, you must specify a purpose key like you just saw in the previous slide. These strings must be within a dictionary keyed off NSLocationTemporaryUsageDescriptionDictionary in your Info.plist like you see in this example. Make sure you explain clearly to the user why you want their exact location to insure they grant you the access needed.

Following on the previous slide CoreLocation will select the string under