Meet Core Location for spatial computing

♪ Mellow instrumental hip-hop ♪ ♪ Hello there! I'm Ilya Veygman, an engineer with Core Location.

I'm here today to talk to you about Core Location for spatial computing.

Whether you're brand-new to Apple's ecosystem or a longtime App Store developer, you probably have lots of questions about the kinds of things this system can do.

xrOS is great at showing you the fruits of your imagination, while Core Location is there to help you have an anchor in the real world.

Today, I'm here to tell you all about how to do just that with Core Location.

For those of you who are brand-new to the Apple developer ecosystem, welcome! I'd like to start off with a simple example to show you just how straightforward it really is to add location to your app.

For experienced developers, it never hurts to review one's basics.

So let's start by looking at some sample code for this demo application associated with my colleague's session, "Discover streamlined location updates." In this actor, we request live updates from CLLocationUpdate, and we'll get them asynchronously down here as they become available.

For more details on the location updates API, please refer to the session associated with this demo.

Apps must request the user's permission before accessing sensitive information such as location, so here, we invoke this API to do so.

In this simple example, we do it when the view inits.

We also have to ensure that we set this string in the app's info under Build Settings.

Again, apps must ask the user's permission before they can get sensitive information such as location, and this string is there to explain to the user why.

It will later be displayed in a prompt shown to the user requesting this access.

So let's see how this looks when we run it in the simulator.

Again, in this application, we ask for location access straightaway because it's a simple example.

This will not always be the case with your apps.

You can see that we get a prompt asking the user if they will grant access to their private information.

Now before moving on, let's chat a little bit more about how Core Location treats user privacy on this system.

Even if you are new to our developer ecosystem, you might already be aware that Apple is heavily focused on privacy in its user experience.

Location access is not an exception to this maxim.

Before you can get updates about geolocation, you must first ask the user for permission to access their location information.

You will not get location updates without user consent.

You can ask for consent on this system by creating a location manager and invoking requestWhenInUseAuthorization, along with setting the usage description string in your app's Info.plist.

This, again, tells the user why your app needs to know their location.

Finally, you should only ask for this access in a context when your application actually needs it.

Not only is this better from a privacy perspective, it also ensures the user is more likely to allow access at all.

Recall that we did this in our sample code since it was a very simple example and starts asking for location updates immediately.

So what does this prompt look like and what does it show? Users will see a prompt from your application similar to the one here.

This may look familiar to those of you watching who already have experience with iOS development.

A user can grant location access for just this session, while using the app, or deny it entirely.

Users may also choose to grant your application knowledge of either their precise or approximate location using the highlighted button, just like on iOS.

For more information on how exactly this precise versus approximate location works, please refer to "What's new in location" from WWDC20, hosted by a younger version of myself.

So back to the demo.

After we grant this application access to precise location and authorize it while in use, we can now start getting location updates and see our app getting position updates.

So what exactly did I mean by "precise location"? That is, how accurately can the headset know a user's location? For a unit by itself, you should expect accuracy similar to that of a Mac, so that's about 100 meters.

This will be sufficient for applications like those used for finding nearby restaurants, parks, and other attractions.

However, if your iPhone is nearby, this device can leverage existing connections between these two devices to improve the location accuracy you would get from the headset to be on the same level as that of an iPhone.

Your device works even better when together with our other Apple hardware.

This opens up a whole new range of applications which can run on a spatial computing system like this one, such as precise weather updates, geotagging, and more.

Now for both newcomers and experienced developers, you've also heard me say that an app is eligible to get location updates while a user is using it.

What this means is fairly straightforward on iPhone or watch, but what does it mean for us? The user experience is, after all, very different from an iPhone or a watch.

So, let's talk about that.

Let us call back to "What's New In Core Location" from 2019 where we discussed how and when foreground apps are considered to be in use on iOS.

For a platform like iPhone, this is fairly obvious.

There can only really be one app foregrounded at any given time.

There is also a short grace period after the app is backgrounded while it can still get location updates.

So what about here? Your application on this platform can be fully immersive, or you could have apps running in something like a window.

"How does Core Location treat this?" you're probably wondering.

For a fully immersive experience, this is straightforward.

As long as the user is running your application, we consider it to be in use and eligible to get location updates, assuming that the user has granted consent for your app to get their location.

On this system, Core Location provides location information to your app, so long as the user has recently looked at the app.

To wit, on this platform, we consider apps running in a window to be eligible to get location updates if the user has consented to giving their location to them, and if the user has recently looked at the app.

Let's examine this more concretely.

Imagine that both of these apps have been authorized to access the user's location while in use.

So long as the user is not interacting with or looking at either app, neither one will be able to get location updates.

If the user starts looking at -- that is, interacting with -- the app on the left, that app can now get location updates, while the right one still cannot, even if it happens to be in the user's peripheral vision.

And this will remain true until the user looks somewhere else, such as at the app on the right, or moves the two apps together such that they can look at both of the apps at the same time.

Just like in iOS, there is also a grace period before Core Location considers the app to no longer be in use.

This means that if the user were to look at an app on the left, then at the app on the right before looking somewhere else, there will be a short period of time -- a few seconds -- when both apps are still eligible to get location before Core Location considers these apps to be out of use.

We feel that such a model of location access provides a good experience on this platform while being respectful of user privacy, since a user would not have their location tracked without their permission or knowledge, particularly since this device is intended to be used interactively, rather than as something which runs stashed somewhere like in your backpack.

As such, apps will not be able to get location updates while they're not running.

Similarly, updates from our monitoring APIs would not be delivered.

So this brings me to something else which many developers who already have location-using apps for Apple platforms are probably wondering about: How will my app behave when running in compatibility mode? So what happens if I just run my iPhone or iPad app with no code changes for a device running xrOS? Let's talk about that a bit.

As already discussed, the "in-useness" of "while in use" derives from where the user has looked recently.

And apps are eligible to get location only when the user is looking at them.

So what about apps which request Always authorization? Apps which prompt for Always will have their request redirected to request authorization while in use.

You will similarly see that Always is not an option for your application under Settings.

Location on this system works best for single-shot or continuous updates while your app is being used.

If your compatible iPhone or iPad app uses region monitoring or our new CLMonitor, it will not be delivered events.

Consider if your iOS app is designed in such a way that assumes a particular API is always supported, and might behave in unexpected ways if, for example, monitoring APIs never deliver events.

Similarly, consider whether your app relies on getting location updates in the background while it's not running.

To learn more about our API in general, especially what's new this year, I would recommend that you watch these other two sessions from my colleagues, as well as any of our other sessions from previous years, especially if you're a newcomer to our ecosystem.

"Discover streamlined location updates" discusses some new developments in our API, particularly around how we recommend getting location updates and ways in which we have made our API more compatible with Swift concurrency.

"Meet Core Location Monitor" further discusses new developments in monitoring APIs, and how we've reimagined the ways an app can get notified about events such as geographic entries and exits.

If location is something you care about for your app, I am certain that you'll find these to be time well spent.

xrOS provides a really cool experience that I'm sure many of you have been anticipating for quite some time.

We have been too, and we worked hard to ensure that you can provide the best possible user experience both for apps which were designed specifically for this device, and for those compatible iPhone or iPad apps.

We also want to make sure that user privacy is respected in the best ways possible, and that a transition to this platform is as seamless as possible for those of you who have existing apps in our store.

Now that said, do consider how your compatible apps might behave in a scenario when they don't receive notifications about events like region changes or visits.

I definitely encourage you to watch any of the other sessions, both specific to Core Location and to spatial computing in general, which might pique your interests.

Thank you and enjoy the rest of WWDC.

♪