And then all you have to do, user decides, hey, I'm ready to use location. And you go ahead and start updating locations. And then with that, we go ahead and give you a callback that says your user moved here. And then you can take appropriate actions such as updating your view.

If you're a fitness app, maybe you store it to some data model. And basically, that's kind of the quick overview of how location works. So with that, I'd like to move on to what we've done in the last year to really kind of improve location. So there's three main things that we've done.

The first is we've improved accuracy significantly. The next thing we've done is we've also improved the availability of location services in general. And then lastly, we've also helped to lower power consumption of location on your user's devices. So their battery can last longer than ever when using your apps.

So let's look at a couple of these things. What do I mean by improved accuracy? So let's consider our lovely city of San Francisco here. San Francisco, if you're in kind of the eastern side in the downtown area, it looks a lot like this, like your major metropolitan area. You get these big, tall skyscrapers that block the GPS satellite signal. So with that, it's called an urban canyon, and it's a really, really difficult environment for GPSs to work in.

And so we actually take devices and we drive around San Francisco a lot. And we particularly pick on this one block that's got those nice buildings that you saw right there. And the result is that we drive around and we look at our GPS performance. And we get something that looks something like this. Now, this looks a little bit sloppy, but quite frankly, most vendors would love to have a location solution that looks as good as this does with just GPS. But we're Apple, and we also have iPhones.

We have iPhones that have Wi-Fi radios and cellular radios and a whole bunch of other technologies baked into the phone. So we don't just stop at GPS. If your user has Wi-Fi, now in iOS 6, they'll get something that's an experience that's a bit more like this. But that's not all. As you know, Maps just launched with some beautiful new vector data, which actually is useful for location as well. So now your experience if you're driving in downtown San Francisco will be something more like this.

There's two main parts. Let's start with what I mean by Wi-Fi aided location. So like I suggested, basically we take the horizontal outliers, say you're driving through San Francisco, and you see these peaks in uncertainty where we really don't know what's going on. You've got signals reflecting through windows, you've got buildings blocking others.

So if we add in Wi-Fi information, we can actually reduce the location accuracy. So we look something more like this. So basically we just take those really, really bad peaks and we drop them back in. And it looks a lot, basically it's an incremental improvement that really helps as a good stepping point for other technologies. So that brings us to map aided location.

So what map aided location does is we basically take the raw GPS and course, the location and course information from GPS and Wi-Fi. And then we look at the, consider the question of is your user driving? Now if your user's driving, A, they're much more likely to be on a road because most people don't drive through golf course.

And the other reason why it's important is because there's a lot more sensor information from driving. So your course is much more reliable. So with that, if we have vector data available to us or we decide to download it, the result is that we can consider all of these things and decide if bringing you closer to a road is more accurate for your user. And so we will improve location if it's possible for us to do so. So the reason we do this is for, say, improving turns. A different part of a drive test, this is the Transamerica pyramid. We have data that looks something like this.

Now it's clear that the user probably didn't go through that plaza. And in fact, if we add Wi-Fi in, you start looking more like this. But again, if map aiding is available because you're driving, the result is this. So this helps a lot if you're trying to understand where your user actually is and you're trying to provide directions or just generally keep track of any sort of location accuracy.

But like I mentioned, we only do it if it's possible. So one of the key tenets of when we turn this on is the question of can we do this without any harm? And so with that, we actually added another spot on our drive test. And we stopped for donuts. And I don't mean the manly donut shop. I actually mean we go into the parking lot and we do donuts.

So this is not an urban environment. As you can see, we actually are doing very, very well with just GPS and Wi-Fi. But we can still do it-- so when we turn on map aiding, we actually don't do much. You're a little bit closer to the roads, but when you get to the parking lot, your user's track is left alone.

And so we don't really have any road data there, and so we leave the user right as they're driving, having fun. So this is really cool that we can selectively apply map aiding when it's really beneficial to users and not when it's going to change their data to ways that don't make sense for you.

By bringing these to OS X, we've enabled the ability to bring the Reminders application to OS X. Reminders now works great on your desktop, home work notifications, they're great. As long as your computer stays running, so if it's slept and not shut down, it'll work just fine. A quick example of how geocoding and region monitoring play together.

If you were going to install a reminder for something that was interesting to the user, like where I work, and then what you do is you take an address, you create a geocoder object, and then you make a geocode request, which you pass a block, will go hit a server, asynchronously call you back, and then you can decide that you want to start monitoring for that region.

And so you just pick the best place mark of your choice, start monitoring for it, and again, we give you this callback saying location manager did enter region, and we have a similar one for exit, and you can just, since this is OS X, you can display an NS alert to tell your user, hey, look, you're back. Great. So you can just go ahead and start monitoring for that region. And then you can just pick the best place mark of your choice, start monitoring for it, and again, we give you this callback saying location manager did enter region, Hey, look, you're back. Great.

So with that, let's talk about some other forms of availability, specifically Wi-Fi availability. So as many of you already know, if you're sitting somewhere and you've got a location and you do a Wi-Fi scan, what we do is we take those results and we send them up to the server. And the server says, hey, look, we know about all these Wi-Fi hotspots in this whole area. Here you go.

And so now your device, without any more talking to the server, can wander around for some finite distance and figure out where the user is. But the problem is, as you're driving around San Francisco and you're hanging out taking photos of people, you know, you take one picture here, you take one picture there, you're not necessarily in the same spot.

We don't hit the cache on the device. So the result is that we go to the network and we download yet another piece of information and you get a new little area. So now you can move around inside of this, but if you move somewhere further, then we have to go talk to the network again.

So with iOS 6, we decided, can we maybe do something better here? Can we maybe compress the data? And so what we did is we actually took all the Wi-Fis and we mapped them into these tiles. So now in the same size as one of those data downloads that you saw on the screen before, you saw six of them, you get one of these instead. Same amount of data. That's five kilometers by five kilometers.

And the cool part is, if you're on Wi-Fi, we don't just download one tile. We'll actually download a whole bunch of tiles in that area so that your user can travel even further around the city. So if you pay for data at a coffee shop and then you use it, you can keep going.

We have 10 times the access points in one piece of data. And actually, because we're smarter about the way that we choose the access points that we put into the tile, we actually get 60 times the coverage area. So it's just being a little bit smarter about it overall and you would get this better performance.

So with that, the advantages of Wi-Fi tiles are a handful of things. First off, it's basically instantaneous location. If we know about the Wi-Fi's that are near you and we see one, we know where you are. Done. Fast. So passbook and weather, everything works instantly. Another cool thing is that we sell devices that don't have cellular radios, which means that if we can't download data, we can't know where you are.

So now that we've got Wi-Fi tiles, we can bring things like region monitoring over to the device. Or you could even say tag photos with information. So an iPod touch, which doesn't have a GPS in it, can now take a picture and know where you are and you can say, hey, look, this was at this place.

But it's not just Wi-Fi-only devices that benefit. Users travel abroad, and they don't like paying for expensive data. And even if they're not abroad, they don't want to take data against their data cap. So by saving some space and giving them a whole bunch more information, we've made Wi-Fi location much, much more available to all users. With that, I'd like to move on to some API changes. So I mentioned that we lowered power consumption.

And specifically, we were noticing a problem with a lot of applications in the store that wanted to run in the background for one reason or another, like fitness applications and driving applications. Let's say that a user is driving down to L.A., and they get hungry. So they stop for dinner. Okay, great. What do they do? They unplug their cord, they put their phone in their pocket.

Are we fixing? Can we get a location for this user? And similarly, we actually can do some activity detection to say, hey, look, if you're a running application and you get in the car, the motion's completely different. We can kind of detect the two and we can pause you just proactively based on activity type.

So what does this API look like? Well, for starters, you need to know whether it's on. And the answer is basically if it's on, if you're compiled against -- if you're linked against iOS 6, we're going to turn it on for you by default. All your old applications will work as before, but we're going to turn it on by default. But we're going to give you a property that you can control to say whether or not this is a good idea.

Similarly, you're going to need to know, you need to tell us what type of activity your user is doing. So we've got a property on the location manager now called activity type, which is going to allow you to set us, tell us the activity type your user is doing. And so we've come up with three basic activity types that you can choose from. The first is vehicular navigation. So your maps application that's giving navigation or your TomTom or Navigon or somebody.

Fitness applications. If the user is running, if the user is cycling, that's a good indication that you're a fitness application. And then lastly, everything else. Basically, those are the two most common types of applications that want to run in the background. So everyone else is kind of lumped into other, which just has some basic characteristics from both of them.

The next thing you want to do is what are we going to do when we pause you? Well, what we're actually going to do is we're actually going to tell you that, hey, we've paused you so that you can respond appropriately. You could flush some data to disk.

You could go ahead and tell the user. You can do whatever. Similarly, if your application is suspended because of a pause event and then later your user launches your application to the foreground, we'll put you back where you were. Or we'll send you a resume notification and we'll reconnect all of your location and you'll start receiving location updates just by the user launching your app.

Because, again, you're not in the background anymore. Your user's actively telling us, hey, look, we're trying to use this app. So we'll put you back where you were. So with that, I'd like to invite up Mike Dal Santo, who's going to give you a quick demo of how to use Autopause.

Thanks, Jay. How are you all doing? I'm going to tell you about Autopause, our new power saving optimization. And our goal for this feature is going to reduce the number of backgrounded applications that are unnecessarily requesting location updates. So what I've got here is your boilerplate fitness application. It's called Autopause Demo.

And as you can see, it's nothing more than a start button, right? And that will actually underneath the hood call start updating location. I've got a table view which will list the location updates as they come in. And then I have a map view which will plot the location updates. So for this demo, you can see that I'm actually simulating a location in our iOS simulator. This is considered our city run. So being that it's a fitness application, I thought it would be nice to actually see these being mapped as if you were running.

So the main point of this feature is that if you are in the foreground, Core Location will have a lot of information about your location. So if you are in the foreground, Core Location will stay hands off. We kind of say that it's up to the user to determine that they are actually tracking. So they know best. We'll remain uninvolved.

As soon as the application goes in the background, that's when we start determining, are these location updates benefiting the end user? If I were to actually background the application while I'm running right now, we would say, yes, these are benefiting the end user. He's registered as his activity type is fitness. And ultimately, he's probably using these. But let's just say that you were using my application here.

And after your run, you got home and you were completely exhausted. And you're like, thank God I'm finally finished with that horrible run. So instead of actually actively stopping the location updates, which would be the wise thing to do, you just put it in your pocket or you put it on your dresser and you take a shower and you completely forget about that.

Meanwhile, we are continuing to determine position estimates. And those are not going to be benefiting you if you are registered as a fitness activity. So to showcase this, we throw this into the background. And during this time, CoreLocation tries to determine, are these updates actually benefiting the user? And in our case where we've stopped running, they are no longer benefiting the user. So after quite a bit of time, CoreLocation will issue you the pause notification. And what that is is it's the CL location manager's delegate callback. Location manager did pause location updates.

So when we actually pause you,

So we've also got the did resume location updates. When your application is brought back to the foreground, this is when we actually will, under the hood, call start updating for you and then inform you via this delegate callback. So I want to clear out some internal state that I've kept for my location controller.

Remove any local notifications so that there's no lingering notifications in the notification center. Obviously that would be a confusing state for the user if they saw it running and the notification center still had some lingering. Please resume my activity. And last but not least, for this demo purpose, I actually post a UI alert view down here just so you guys can actually see underneath the hood what's going on.

So to run through this one more time, we are still in a tracking state now, so I'm going to push the application to the background. So CoreLocation is actually churning on every position estimate that we actually are going to give your delegate. And we're going to determine, is this benefiting the user? After some time, if you're no longer moving or if you're indoors and you're not able to get a GPS fix, we'll say, obviously, he's just draining battery. He's wasting the user's precious power. So let's go ahead and pause them.

So you can see that we were issued the pause notification. And I kind of missed it, but I wanted to actually note on the fact that under settings now and in the status bar icon, we've increased the delay timer from the status bar icon. We've left it in the status bar there for 10 seconds.

And under privacy, we've left it next to your application right here for an additional minute. And this is because we don't want it to be any mystery for your users that your application was using location. So now you have a clear indication that within the last minute or so, this guy was actually using location.

So as I mentioned before, if the application were to take the foreground, we would resume location updates for you. But if the application is killed via by the user actually killing it manually or if the system is under load and needs your resources and has to actually kill your app, we will not resume location updates for you. So that's what I'm going to do this turn around.

I'm going to kill the app. And you'll see the next time we launch the app, The app is launched with options, or did finish launching with options, as if it was the first time it was ever launched. So the user can actually go back and look at his last run and marvel at not being resumed when he wasn't hoping to be resumed, essentially. That's pretty much all there is for Autopause. A key reminder is please set your activity type. Help us help you. Let us stay completely informed of what you're trying to do. And other than that, we look forward to saving some battery life with you guys.

Thanks, Mike. So Mike gave you a quick example of how you might respond to a pause event from us. And so I wanted to go over a couple of other ideas. So the first idea is that we're only going to pause you when we're actually sure that the user is not interested in your location data.

So if you receive a pause event for us, it probably means you shouldn't be running because your user doesn't expect you to be running. So with that, the easiest thing you can do when we send you a pause notification, don't do anything. You can log into disk maybe if you want to keep a note for yourself while you're debugging. But what it comes down to is there's usually no action required. Your user is just not expecting any more activity from you.

The next thing you might want to do on an event is to do exactly what Mike described. If you're a fitness application and you're expecting to be in the background a lot, maybe you send a notification to the user or maybe if you've got their headphones in, you send them a quick little audible saying, hey, by the way, I'm stopping your activity because you're stretching now.

Another thing that you might want to do, especially in the fitness app example, is just stop updating locations. You can go from pause to stop just by calling stop again. And if you agree with us that you agree that the user is no longer doing what you thought the user was doing, there's no reason to be running. If you're a fitness app and you're paused and you then stop yourself, the result is that when you come back into the foreground, the user can now view your old track and maybe start a new one.

You don't randomly have data from like a couple days later being added to a really old track in the user's UI. It's not a good experience to necessarily just be paused and then resumed. Sometimes you do actually want to stop. But this is not going to be enough for everybody. So I'd like to talk about a couple of other responses that you might want to have.

For 95% of you in the room, this is not the slide you're looking for. Please just ignore me, go to sleep, do whatever, it's after lunch anyway. So one thing you could do is you could actually just disable auto pause. As I mentioned, it's a property. You can just go ahead and set it to no. And we will just turn it off. You will be fully responsible for the user's battery and the user's location and that's all up to you.

Maybe you want to do that. This is tempting to you. I'd like to suggest maybe two other approaches that are kind of a compromise on power. The first is consider the case where you're driving and the user's followed every single one of your turns as you're going down the street and you get a pause event from us.

The second is consider the case where you're driving and the user's stopped moving. Well, if you know they're still on the freeway and you know that they're still doing what you've told them to do, there's a good chance they just got caught up in traffic. So it's entirely possible that there's some cases where you might want to restart location. And we make this possible to do.

You just call start updating location. And even if your app is still in the background, we'll give you a little bit more time to run and we'll think about whether or not you should be paused again. And so if your user starts moving again, we won't pause you. If the user still stays there, then maybe we'll send you another pause event.

So it's kind of a way as a compromise to say, hey, look, I actually in this case know better than you. But here's a hint. If you've been telling the user to make U-turns for the past two minutes, maybe they're actually sitting in a restaurant and they're no longer driving. And maybe we're right and you don't actually know what the user's doing anymore.

One other idea is if you had an app that was just generically kind of wanting to log the user's activity as kind of a path or like some sort of activity, just generic, not necessarily fitness. But just kind of, hey, where have you been in the world? It might be possible that the user's gone home for the night.

You'd like to kind of pause temporarily and then start again in the morning. And it's actually easy to do this. But it's always been possible. You could have just stopped yourself and then installed a fence. So geofencing would allow you the ability to resume yourself if you paused. Now, again, I really strongly suggest that you guys don't do this.

I think that most users are not going to expect this behavior. If your app runs almost indefinitely as far as a user's concerned and every other app runs indefinitely, then you're going to have to do this. So I would strongly consider trying out auto pause as it is. Just tell us your activity type. See what it feels like. And then if you have problems or you want to tweak performance, you can go and kind of do this. So for the rest of you, most of you can just forget this slide.

So with that, we have a couple of other API changes that we've made in iOS 6. So the first off is sometimes it's useful to us to notice that, hey, look, you're not necessarily handling location updates as quickly as we're sending them to you. So rather than waste CPU cycles sending you messages, what we might actually do is we might want to coalesce a handful of messages into one, just give you an array of location objects. So with that, we've actually got a new delegate callback method that just takes an array.

They're just chronologically ordered. The last one is the newest one. So if you fall behind and we actually send you a couple, then what you want to just do is look at the last element, plot that on the map, and then just throw away the rest because your user's not there anymore.

So with that, we've actually deprecated the old API. If you're targeting 5.1, obviously you need to still use this API. But on 6, we actually, if we see both, we'll only call the new API. So your new delegate. So the way that you want to handle this if you're trying to do 5.1 and 6 is just implement the old delegate, pack up the object we give you into an array, send it to your new delegate, and implement everything in your new delegate. And that'll allow you to run on both platforms.

The next thing I want to talk about is kind of a quick overview of privacy on iOS. So as you know, iOS 6, we're doing a whole bunch of privacy controls for all of the user's personal information. Now location has always been considered personal on iOS. And so it's always been possible, whenever you've tried to use a user's location, we pop up a dialog that looks like this.

So we tell the users, hey, this application is trying to use location now. And then you tell the users, hey, this is why I want access to this user's private information. And if you give them a compelling enough reason, they'll say, okay. If you don't give them a compelling reason, they'll say, go away.

And if they do this, you still want your application to work. So keep in mind that you might not always have location because the user might not trust you with it. Or maybe they would just prefer to type in an address and let you geocode it and then find something. Or maybe they just want to keep it private.

Or maybe they just want to go to a region in a map that they're not actually physically at and use your data that way. So I guess one thing to keep in mind is that it's entirely possible that the user will prevent you from using their actual location.

Similarly, 5.1 still uses the purpose string, so 6 will still support it as well. But if we see both, we'll prefer the Info.plist string over the purpose string. You might actually want to read the Info.plist string out yourself and set it to the purpose string if you're targeting 5.1.

With that, I'd like to move on to talking about basically performance tuning. I'd like to start off with two myths that I'd hope to dispel. I saw an app in the App Store recently that actually told its users that if you want to get a location fix in this application quickly, you should launch Maps first and then launch my app because Maps gets location faster.

Maps uses the same API that you guys have access to. So if Maps is loading it faster, it's a function of what Maps is doing versus what you're doing, not what we're doing under the covers. And the reason why Maps loads location faster is because they're constantly engaged with the user. They start off with a location fix. They take a high-level cell fix that looks like this. They know you're in the Bay Area, so they just start bringing the map there.

You get a better cell fix, and they start bringing you a little bit closer. And eventually, you get a Wi-Fi, and they zoom in a bit more. And eventually, you get GPS, and you get this nice little pulsing dot that says, "Hey, look, I'm out in front of aisle 1." And so if Maps is doing this, engaging their users up front, maybe you could be doing the same thing.

So consider the case where you're just a restaurant app, and I just went ahead and mocked one up here using Maps. You get to the Bay Area. You could say, "Hey, look, here's some awesome restaurants. These are the four best restaurants in the Bay Area." Any user that ever flew to San Francisco would want to drive to one of these restaurants, and you could just make it available on a device for them, ready to go as soon as you get any sort of location.

Or maybe you get a little bit better, and you actually, say, have a couple of bookmarked restaurants the user particularly likes or hasn't tried yet. Maybe then later on, when you actually get a Wi-Fi fix, that's when you actually care, "Okay, I'm in this neighborhood. Maybe now I should go download some new data and say, 'Hey, look, if I'm at Apple Campus, there's BJ's and there's Cafe Max. Those are your two dining options.'" And then lastly, GPS, maybe you could tell me how to walk to Cafe Max if I don't know how to get there from my office already. But the point is that most of these scenarios don't require a GPS fix.

So if you're sitting around waiting for a handful of seconds just spinning or showing a gray background, your users are bored, and they might click out of your app because your app's not providing them functionality. So engage your users up front. So with that, I want to talk about another myth.

Now, the myth is basically that Wi-Fi -- you should turn off Wi-Fi in order to improve location accuracy. And I think this comes about when you've got a fitness application that's considering a user's run track, and all of a sudden you get a Wi-Fi fix that's a very low accuracy, and it kind of pulls you off that track.

Well, the answer there is to filter it. And the reason why you want to do that is because turning off Wi-Fi doesn't improve location accuracy. Again, this is an example of our drive test in San Francisco. This is what you get with just GPS, nothing else. So let's go back to our test.

If you turn on Wi-Fi, even if you're running or if you're in a car, you get this. And if you're in a car and you've got Wi-Fi on, you're going to get something like this. So it's really not beneficial to your users to tell them, "Hey look, turn off Wi-Fi.

Just look at the horizontal accuracy of the position we report to you and just filter it out. Say, 'Hey look, this is not useful to me. I'm just going to ignore this one location and wait for the next one.'" So again, user experience, no Wi-Fi, with Wi-Fi. Leave Wi-Fi on.

I went for a run in San Francisco, just kind of generically wandered around a couple of different streets. And I ended up with a location track that looked like this. Now, this is San Francisco, you know, location is not necessarily the best, there's all these skyscrapers and this and that and the other thing. Well, actually, I left my iPhone at home. I strapped an iPod Touch to my arm and I got this track. An iPod Touch doesn't have a GPS. So this data is purely Wi-Fi using the new tiles.

Similarly, fencing. If you wanted to go ahead and monitor a specific region, you could just tell us, hey, look, I want to monitor this region. Or, you know, I'm no longer interested in this region. And we'll tell you, hey, look, the user's now gone to work or the user's now left for the day. And it's really easy to actually install fences that are relevant to your users. You'll have the appearance that you're running when the user needs you to be running, but you're actually not most of the time.

And then lastly, something to keep in mind is that you can always tell UI application, hey, I want to run longer. So why not just go ahead and begin a background task and then start location updates, wait for the level of fix that you want, turn it off, and then you're done. So with that, I'd like to suggest a model for starting responsibly. So let's consider, again, the automatic check-in app.

What do you want to do when you want to start location? Well, you want to make sure that you can run for a little bit of time in the background. You know, Springboard might give you 10 seconds. With this, you can grab, say, five minutes. And then if Springboard says, hey, look, you're out of time, you go ahead and stop location.

But five minutes is still a really long time. So what you should actually do is you should start a timer for you. So let's say that you had a method in your function called start location timer that just started a timer saying, hey, look, I'm trying to get a location fix.

So with that, what you could do then is you could actually, when that timer fires, say, after 30 seconds, maybe a minute, you could just shut down location yourself. Say, look, for some reason, I'm not fixing. I'm just going to turn everything off. And that's much better than waiting for us to pause you because, again, we're viewing it very conservatively. And so we're going to take longer than a minute or two to be able to determine that the user's not actually getting anything useful. So you can do it much better with your own timer.

Then once you've set up the safety mechanisms, all you have to do is you're going to go ahead and start the timer. You start calling the location updates like you've already been doing. And then maybe go ahead and save a little bit of state for yourself saying, hey, by the way, I'm running.

So in that case, if you were, say, now going to implement a significant location change handler, again, it's just the same handler as before. So this is the new one. Location manager did update locations. And in this case, let's say you launched due to an SLC event, a significant location change event. The result is that you could look at that location. And you could say, hey, look, is the location that we gave you? Take the array. Grab the last object. It's the most recent one.

And you could say, hey, look, is the accuracy of this thing good enough for me? If it's too large, then maybe I don't really care that I'm in this city. I actually was trying to figure out what bar I'm at so that my friends can come find me. So just go ahead and say, look, it's not good enough.

If a location's already started because you're keeping track of that, you just sit there and wait. Eventually a better location will come in. And you can respond with that location. Otherwise, don't worry. You can go ahead and start location. Now, if you were launched due to an SLC event, you've got a handful of seconds to do whatever you need before you get suspended.

Since you already wrote the start location function, now we're going to go ahead and grab that task assertion. And we're going to get you some more time, which is very useful. Now, eventually, sometime later, that better accuracy came in. Wi-Fi kicked on. Or you got a GPS fix. And you now know exactly where the user is. You're ready to tell the world about it.

Update the view. Or update your data model. Or send it to the server. Do whatever you want. And then you're going to implement. Your own stop location method. I've omitted this from the sample. But your stop location event is going to do the exact opposite of your start location event. It's going to stop the background task assertion.

It's going to turn off the location timer. And it's just going to stop location and set the flag to none. So it's really easy to run in the background for short intervals of time without using the UI background mode's key. Which is just really -- it really will allow the user to run better in the background.

Autopause is really just designed for the apps that actually are trying to run in the background. And it's going to run a long time in the background. I'd like to give you guys a quick summary. So what we've done this year is we've made horizontal accuracy better than ever.

We've made location more available than ever with both Wi-Fi on iOS devices and making APIs available like region monitoring on OS X. And then lastly, we've made power consumption better than ever. But in return, I want four things from you guys. First off. I want you to run only when you're needed. Autopause is great. But consider SLC and consider region monitoring. They're powerful APIs that will let you run when you actually intend to.

Then I want you to tell the user why they're using it. And I want you to use the new NS location usage description key. And I want you to honor that contract. Don't let your users be surprised by the arrow popping on. Actually just do what the user expects with their location.

Next, specify user's activity. If you're being a map application, tell me your other. If all of a sudden the user gets in a car and you start giving them driving directions, flip your activity type to vehicular navigation. Keep me up to date about what the user's doing and I can help make sure your app gets the best performance out of AutoPause.

And then lastly, leave Wi-Fi on. Don't tell your users to turn it off. Let your users get the best location experience possible. I'd like you to point you to a couple places for more information. Paul Marcos, pmarcos at apple.com. He's a great point of contact. He's definitely helped me with these slides and he's really been a good resource for just interacting with you guys. We've got some documentation online. We also have developer forums.

Feel free to check those out. If you've got a time machine or you just go ahead and online later, you can go ahead and watch the using map kit app because many of you will want to use location by presenting it to the user using maps. So I would recommend downloading that after the sessions become available.

CoreMotion is another great way to provide context on your device. Knowing what the user's doing with your device is almost as powerful as knowing where they are in the world. So go ahead and check out Andy's talk on Friday. So with that, I'd like to thank you for coming.