位置情報に関する新機能

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 WantsToNavigate to then display to the user. It's important that you put these strings under this dictionary as CoreLocation will only look under this path for your purpose keys. The prompt the user sees will ultimately look something like this. Note that the purpose key is shown to the user just above the map inset and explains why the app wants their exact location.

Temporary location accuracy upgrades work a lot like things to do with the "Allow Once" behavior introduced in iOS 13. That is to say your user will be prompted for an accuracy upgrade the next time they relaunch your app and trigger the feature that requires a temporary accuracy upgrade.

This upgrade last as long as the user keeps using the app, so as long as they don't close it, you won't have to ask for it again. OK let's bring all this together and see how it works. Your user sees a prompt indicating what location info the app would get, were they to grant exact location.

Upon allowing this, the app can now proceed to give navigation instructions from their exact location to their destination. So, just a few takeaways to consider before we move on. You should make sure your apps location- based features are able to deal with not having been granted full location accuracy. Maps is a really good example of this. They might seem like an app that would always require full accuracy location but they deliver a great user experience in both full and reduced accuracy authorization. When they lack full accuracy, it's reflected in the UI to the user with both the large position circle and the status bar at the top of the UI. This UI reflection is worth a strong consideration when making your own app. Sometimes, however full accuracy is needed. At that point, it's perfectly fine to ask the user to grant full accuracy. Maps does this well by showing in the search bar that it needs exact location to navigate from the user's location to the destination and will then prompt for it if the user selects this option.

Asking for full accuracy only when it's actually needed makes users more likely to give you what you need. It shows that you're not asking for more information than is necessary. Following on this you should also make sure to use purpose strings for accuracy upgrades just like you would with location authorization in general. Explain to the user why it's necessary. You can have more than one feature per app that needs full accuracy so you can have as many such purpose strings in your info.plist as you need. When asking for full accuracy it's often better to use a temporary upgrade prompt rather than to send the user to Settings whenever that's possible for you. Now let's talk a bit about how to consider background location updates in light of this new accuracy authorization. Let's start with significant location change monitoring. This monitoring adapts well to reducedAccuracy. You'll get updates no more often then you would with didUpdateLocations results. About four times per hour. Similarly, we do not deliver duplicate locations if your position has not changed enough to have also changed your reduced accuracy location. When accuracyAuthorization is reduced, visit monitoring API is still accurate in time. It is only the spatial information which is reduced in accuracy. Let me explain what this means. Let's say I arrive at work bright and early in the morning. If I have two apps monitoring for visits, one receiving fullAccuracy, one receiving reducedAccuracy, then the full accuracy app will receive a visit notification that I arrived at coordinates within Apple Park at 10:08. But the reduced accuracy app will receive a visit notification that I arrived at coordinates somewhere within Cupertino but still at 10:08. Finally, Beacons and regions. Region entry and exit notifications will not be delivered for apps that are not authorized for full accuracy. You will need to get full accuracy to use this feature. More on this in just a bit. We know that there are many apps which use region monitoring to deliver features to users. Let's look at one popular example, Reminders. As you probably know Reminders can deliver location based reminders to the user by setting a perimeter around some location.

Let's see how they adopted the new Accuracy Authorization API. I have a reminder set for myself to buy some tuna for my cats. And I want to be reminded of this when I'm leaving work so I don't forget this incredibly important task. Let's see how this works in the canonical example with full accuracy. Now I can authorize tapping the reminder and then go set a location for this reminder. Here I'll be able to set a region around my office such that I'll be notified when I leave work. OK so great. I'll be reminded by some tasty tuna for my cats as I leave work. Let's see this again but this time with reduced accuracy. You remember how I told you that region monitoring won't work in this configuration. This time reminders prompts me to go to Settings to turn on full accuracy. It's correct for Reminder's to do this here rather than to ask for a temporary upgrade because this app needs full accuracy at all times to deliver timely location-based reminders. Now the user can choose not to grant full accuracy here and still set a location for the reminder. But this location based reminder won't fire on any device where the user has not granted full access.

So a few key takeaways for background location updates. Region monitoring requires full accuracy. So apps needing it have to have full accuracy granted to them.

While it might be tempting to always check at launch if your app has full accuracy and then send the user to Settings if you don't you should think carefully about whether that's actually necessary. Not every app needs the user to grant them full accuracy at all times. When it's possible, design your app in a way that will let the user interact with it without having to increase the authorized accuracy. This will make for an overall better user experience and make the user more likely to keep using your app. As I mentioned at the start of this talk there exists a set of applications that really do not need more than reducedAccuracy locations. I previously talked about how to get full accuracy when you only have reduced. So now let's talk about the inverse case. Even though you might be authorized for fullAccuracy it doesn't mean you should get full accuracy locations if you don't actually need them. Luckily you can set your location manager to get only reducedAccuracy locations when that makes sense. We introduced a new CLLocationAccuracy constant that you can use to put your location manager into this mode. You can also change your app's behavior to request reducedAccuracy locations by default when asking for authorization by setting this key in your Info.plist. Note that there is no Precise:On pill in the Map this time. This is another effect of this key. It prevents the user from accidentally giving more location access then they intend. In some cases the user may want to go back and change their mind about having granted reduced accuracy to their app. And they can do so simply by going to Settings and toggling the Precise:On switch. This is still going to be available despite the mentioned info.plist being set. Let's have a look at an example app that does request reduced accuracy locations by default, TV. Many of us are familiar with region locking for streaming content as well as television blackouts for sporting events and pairing with local affiliates. With the proliferation of content streaming services like Apple's TV app there is a legitimate business need for video streaming applications to know the locations of their users. But like we discussed before that doesn't mean the app needs to collect more information about the user then is actually necessary.

TV only asks for location when it actually needs it and when it does it only asks for approximate location. If I feel like watching some sports I would go to the sports tab then find the game and tap it to watch. If I click on one of these games. TV verifies my location and after granting location access it only gets my approximate location. But taking this approach TV still respects broadcast rules while minimizing how much information it has to collect about the user. So by now you've probably wondered how exactly these locations work and you're probably thinking that desiredAccuracy was doing this for you all along. So I like to talk about that for a bit. desiredAccuracy is a property that we introduced to encourage you to only use as much accuracy as you need. There are many reasons for this but the foremost was to allow iOS to save battery life. Now, this is different from what we now have with reducedAccuracy in two ways. First there wasn't actually a guarantee that you would get the desired accuracy asked for either because there was a lack of a GPS signal or because there could be another app running simultaneously which is receiving more accurate locations that we would then opportunistically deliver to your app. Second, there was not an effective way to surface this information to the user. That is the user really had no control over how much information an app would get. So what does this new API actually do. It might be tempting to think that reduced accuracy locations are simply your true location with some noise added in. But that is not the case. Simply adding some random noise on top of the user's true location is actually not that secure against someone who might wish to disambiguate the true location. Instead it's better to think of what happens under the hood as a quantization of sorts. Let me explain further.

Let's look at an example area. Consider different users going on a drive in the vicinity of El Paso, Texas and Juarez, Mexico. Note that this is near an international boundary, with the US being in the northern half of the map, and Mexico being in the southern half, bordered by this pink line you see here. The true position of the user is represented by the cars while the reported position, that is to say what an app would see if it had reduced accuracy, will be shown by a circle. Again as I mentioned earlier in this presentation, these reported locations will contain the user's true location.

As these users drive down Interstate 10 the location snaps to within different quantize regions of varying sizes. Both the red and yellow users are going to be quantized or "snapped" into the same regions as they drive along the road. But the amount of snapping will vary. In denser urban areas, this amount of quantization can be a couple of kilometers, but in less dense places like rural areas, it can be 10 kilometers or a bit more. A typical value for this quantization radius is around five kilometers. Note that despite the cars continuously driving along the road the region to which the true position quantities will not continuously update. This is because Reduced Accuracy locations are recomputed about 4 times per hour. So depending on exactly how fast these cars are moving there might be some lag between quantized snaps. The actual semantics of the quantization are intended to replicate what the user would expect to hear if they were to ask for an approximate answer to the question "Where am I"? We tried to ensure that the resultant reduced accuracy location is still going to be somewhere that the user actually expects to be. We use a location we have for you to place your approximate location on the appropriate side of the border here.

Again though remember that the center point does not represent the location of the user. It only represents the center of a region where they approximately are. Approximate location snapping however might put you in a neighboring city especially if there are cities close together. To reiterate the bit about quantization around borders, let's see what happens to someone driving on the other side of the border in Juarez and what they might expect to see.

Note that the blue car is quantized into regions whose centers are on the Mexican side of the border. This new reduced accuracy API is available in iOS and watchOS. And apps accuracyAuthorization status is synced between companion apps on paired phones and watches just like the canonical authorization status.

We've also made an improvement to watch connectivity for sharing your apps authorization status. We introduce this capability in iOS 9 and we've made an improvement this year. Now, you'll be able to share apps temporary authorization status as well as end user state across both platforms. This means that if a user selects 'Allow Once' on your companion watch app or does a temporary accuracy upgrade, your phone app will be able to benefit from that decision. No more needing to ask for permanent authorization when you don't need it. In summary, this new API brings with it a whole new dimension of location authorization. And with it you will need to consider how your app should change to accommodate the user giving you only reducedAccuracy.

If you have features that do require full accuracy, think carefully about whether you really need permanent full accuracy or whether you can use a temporary upgrade API. Whether your app uses background location updates will help you to inform this decision. Finally, consider whether your application could utilize reduced accuracy by default. There's no need to get more information from the user than is actually necessary. A few more things about CLLocationManager. First we'd like to address the changes we made in iOS 13 for always authorization. For some apps, we made some improvements in a recent release. You may recognize this diagram from last years presentation, and that it was not possible to get always authorization without first going through the provisional always state. The idea behind this was to help the user understand always authorization by asking them to address it within the context of where it was actually being used. But for some apps this made it tricky to know when location updates would actually be delivered.

Asking for always permission when authorized whenInUse would put you into the provisional always state just like it would had you asked for it from notDetermined. We've changed this up in the latest releases to better balance functionality and privacy. Starting in iOS 13.4 we slightly changed the state diagram to provide a more deterministic path to always authorization. An app which has previously asked only for whenInUse authorization and got it may now request always authorization and have the user immediately be prompted to consider granting it without leaving the app's context. If you need to know exactly when Always authorization has been granted to your app, please consider this. Don't ask the user for always right away. Instead ask for whenInUse the first time they access location features. Only ask for always once the user accesses a feature that really needs it. If users better understand why your app needs authorization they're more likely to grant it. One last thing. We've had feedback from developers that are using activityType in their apps. And we wanted to rehash some recommendations for you. The activityType field on CLLocationManager helps inform our underlying positioning algorithms give you and your users a better experience. And it's important to use them correctly. Airborne should only be used for actual airborne activities like flying. Fitness should only be used if the user is specifically intending a workout session like an outdoor run, a swim or some other sport. automotiveNavigation is a special case of positioning where you know the user will definitely stay on a road like if they're driving a car. Selecting best accuracy for navigation here is also a good idea. otherNavigation is when the user is definitely moving but not necessarily going to be on the road. This includes cases like Off-Road Vehicles, Hikes, Boats, Walking and so on. Others should be used when you don't have something that will neatly fit into one of these other buckets or has no clear user intention like a workout. OK, let's talk about App Clips and Widgets. You probably heard about App Clips in this year's keynote.

These are a great new feature that will enable an entirely new experience for your users. I'm not going to spend too much time rehashing exactly what these are. And you can look at this talk to get more information on that subject. The key point for us to remember though, is that these are essentially a lightweight subset of a corresponding app. This concept applies to using CoreLocation within App Clips as well. From our perspective App Clips are more or less the same as the corresponding apps, but with two very important distinctions. First, they will not receive Always authorization. Second, instead of "While Using," they will see this - "While Using Until Tomorrow." This means that they get While Using authorization only temporarily. The authorization is automatically cleared the following morning after being granted.

So, in terms of design considerations, don't put any features into an App Clip that would require Always authorization because you can't get it.

You should also remember that App Clips Location authorization expires. Cinderella can use an App Clip to hire a pumpkin carriage and a gorgeous dress for the night. But just like her magical accoutrements the App Clip's location authorization disappears by morning. Finally I'd like to touch briefly upon WidgetKit. This is an awesome new feature in iOS 14 and the new macOS that you should definitely check out. When making a widget that uses location, you have to include the NSWidgetWantsLocation key in your widgets info.plist. You should also consider that widgets are not able to show authorization prompts. Their authorization will derive from the parent app. So if you have an application whose experience will be primarily driven by its widget you will need to consider how to prompt for location access in the parent app should you need it. Today we talked about some big changes to location authorization. A whole new conceptual dimension. Giving the user more control over their data privacy is important to Apple. Users are increasingly conscious of how different services use user data. And location is a prime example. When you design an app to account for reduced accuracy you can deliver an amazing user experience and build trust with your users by showing them that you're not actually asking for more information than you need. We also talked about two types of apps entirely, App Clips and Widgets. And how to use CoreLocation effectively in them.

These are great tools that were designed by a troupe of amazing engineers. And we hope you get the chance to try them out. If there's nothing else you'll take for my talk then please just remember this. Don't ask the users for more information than they want to share with you and that you truly need. This isn't just for the users benefit. It's for your own too. Users don't want to give away more information than they have to. And by minimizing what you ask for, you can build trust with them and give them a better user experience. Think about your features. Think about what they do. And think about what can work with reduced accuracy.

Thank you.