Welcome to Integrating iOS 7 Technologies. My name is Paul Marcos, and I'm the App Services Evangelist at Apple. Now all day we've been talking obviously about iOS 7 and all the new technology that comes along with the new version of the operating system. And there's a ton of stuff that we put out. And this slide is actually pretty common. Every year we put out a new version of iOS, and it has a whole bunch of new technology in it.

And I think one of the challenges that app developers like you face is with every year figuring out, how do you take this new technology and do something with it? How do you apply it in practice in your application? Now in this session, we're going to continue talking about some of these new technologies. I'm going to cover three new areas. And I want to do so in a way that really helps understand how you can apply this new technology and enhance a couple specific experiences that the people using your apps have when they use your apps.

So the three areas that I want to talk about are first, background transfers and how you can use that to minimize your install time of your app. Second, I want to talk about multitasking, which John talked a little bit about this morning, and how you can take advantage of new APIs to make your app always be ready for when someone wants to use it. Paul Marcos And then lastly, one of our most exciting new technologies is iBeacon. So we'll talk about how you can use that to really enhance the location aware app that you may be developing. Paul Marcos So let's start off with background transfers.

And the experience that I want to focus on here centers around this alert. I'm sure you're all familiar with this alert, the cellular download limit alert. Your customers will see this when they try to install your app and they're not on a Wi-Fi network if your app is over a certain size. Now, we just raised that size from 50 megabytes to 100 megabytes, and that's great. But if you have an app that's still over 100 megabytes, this is a problem for you.

And in fact, this is one of the most common questions that we're having. One of the questions that we get as evangelists at Apple is how can I get my app under the cellular download limit? How can I get it under 50 megabytes or now 100 megabytes? And that's an interesting question, but it's not really the right question.

The right question that I think you should be focusing on is how can you minimize the install time of your app? Because that's really what matters to your users, right? From the time they tap buy or install, in the App Store, to when they can use it. That's the important amount of time, and that's what I want to focus on, how you can minimize that.

Now in order to do that, I have a checklist of just three simple tasks that you can perform. The first two of take inventory and use compression, those are really actually just best practices. So some of the things that we hear come up time and time again when we talk with developers.

And then the third one, download things later, that's where the new technology in iOS 7 comes in. So I'll go through all three of these, starting with taking inventory. And what I mean by taking inventory is I want you to perform this exercise with your app. So using iTunes, go download your app from the iTunes, or from the App Store, excuse me.

And once it's downloaded, You can go find the .IPA file that got downloaded. And that .IPA file is really just simply a zip file, so you can change the extension to .zip and you can expand that archive. So now you have the files that were delivered from the app store.

In that zip archive, you can find your actual app bundle. And using the finder show package contents command, you can open it, and then you have access to all your files. And what I want you to do is review every file that's in there. Think about why is this file here? Sort this list by size, biggest first, and go through it that way.

And I think a lot of you will be surprised by the things that you find in there. And I know that because we talk with a lot of developers and we do exactly this, and there are a lot of really surprising things in your applications. So we regularly will find things like readme files. We find Photoshop documents in apps.

You know, iOS doesn't render Photoshop documents, so why is it there? We find source files, things copied in from, you know, third party libraries. A lot of these end up in your app bundle simply because you dragged it in Xcode and inadvertently added it as a resource for the application. So that's really what you're trying to identify here are files that got added as resources and now you're shipping them through the app store.

Another category of files that we find really commonly, are just obsolete resources. So things that were there legitimately at one point in time, but your designs have changed, right. You maybe have changed your UI. A really good example of where this might happen, and something you should watch out for, is you've probably all been working on an iOS 7-based design, but you're still supporting iOS 6. But when you drop support for iOS 6, you need to make sure that you go through your resources and clean out all the old artwork, right. That's a really common thing for us to see.

Another place where you can get some great space savings and just throw out some trash is in artwork like this. You might have a button where those middle pixels, they're really just repeated pixels stretched horizontally, and they're really just taking up space on disk. So using Xcode 5's new slicing feature, you can actually express that these middle pixels can be repeated, and we can stretch that at runtime.

So at build time, what we'll do is we'll actually compress that graphic for you. And then at runtime, we'll automatically stretch it with no performance penalties. So this first item of taking inventory really just amounts to take out the trash, go in your app, and get rid of all the files that are taking up disk space that don't need to be there.

Now the second one, use compression. Now more than likely you're already doing this, but it doesn't hurt to double check. And you want to focus on the things that take the most space, like video. You want to make sure you're using H.264 compression. You get great compression and space savings on disk with no sacrifice in quality.

Same thing for audio. If your app has audio tracks of any length, you want to make sure you're using AAC or at least MP3. And for really good savings, if you're using 44.1 kilohertz right now, consider dropping that sample rate down to 22.05. Most users will never even notice a difference, and you can get a good space savings.

And then for images, for photographic image content that you have in your app, make sure that you use JPEG instead of PNGs. And let me show you an example here. So this is the Starwood app. It's a travel app. They have these beautiful photographs of beautiful places in the world that you want to go visit.

And I did a calculation on this one where if these images were shipped as PNGs instead of JPEGs, the app would be 20% bigger than it needed to be. That's huge. That's very easily the difference between being over the cellular limit or under the cellular limit. And on all of our hardware now, we can do hardware accelerated JPEG rendering, so there's no penalty in using JPEGs.

And in cases like this, with these beautiful photographs, users aren't going to notice a difference. Even on a retina display, you can get great quality using JPEG and save space. So those are the first two items. And these may seem really basic, and you may say, I'm already doing this. But we see this time and time again. So it really warrants kind of going through it here because it is a best practice, and I'm willing to bet that almost all of you would benefit from these two things alone.

Now, going beyond that, this is where iOS 7 technology comes in. You could consider downloading things later. And what I mean by that is consider taking assets that are in your app store bundle and removing them, separate them out, and download them at a later point in time after the user has installed the app.

Now, the important thing to note here is that this really, this may not be right for all applications. This is something that you have to evaluate for your app. Simply, there's no single right answer for how to do this. And you don't want to sacrifice a user experience of that first install and first launch by doing this.

But if you can come up with a way to separate your assets, and I've got a couple scenarios that we'll talk about, then this might be the right thing for you to consider doing. And it can really improve this experience. It does come at a cost of complexity a bit. You may need to represent in your UI the state of these additional files that need to be downloaded.

You certainly have to handle the case where these files are missing, right? The disk may fill up and you may have to present to the user something that makes sense about pieces are missing. Those are scenarios that you don't have to worry about if you include them in the app store bundle, because from your perspective, that's an atomic operation. Either everything is there or it's not. And this certainly will complicate your testing matrices, right? You just have more scenarios to test to make sure that your app behaves correctly.

So to accomplish this, the new technology in iOS 7 that we've introduced is the background transfer service. So let me just give a quick overview of what it is. Simply put, it's a service to upload and download content in the background. And when I say background, I don't mean like in a background thread that you create or you manage. I actually mean it's done in a different process altogether, right? It's done in a system daemon. So it's a service to upload and download content in the background.

And the great thing about this is that means that your app can actually be suspended or it can even be terminated, and those background downloads will continue. Primarily, this is intended for large amounts of data, so things that would take long enough that you might not be able to do them in your process before the user leaves your app.

And after these transfers are done, even if you have not been running in the foreground or your app was terminated, your app will get relaunched in the background and then you can process the results of these transfers. So this is just a new set of functionality that you just simply couldn't do in iOS 6. And in order to do this, you use a new class in iOS 7 called NSURLSession. And let me, I can just go through a simple code example to give you an idea of how the API works.

So the first step in doing this is you create a NSURLSession configuration object. And there's a couple different types of these configuration objects that are available in iOS 7. I'm focusing on this one that you get by calling the background session configuration object. Because that's the one that will hand off work to the system daemon in the background.

Now once you get this configuration object, you're ready to set up a session object, an NSURLSession object. So you specify the configuration you want. And then you provide a delegate and a delegate queue. And we use a delegate pattern, which is very common throughout our APIs. This delegate is the object that will be called back when we need to ask about authentication challenges, that we want to notify about progress, or when the transfers are completed.

And now you have a session object in your hands and you're ready to begin adding tasks to it. In order to do that, you have a URL, which is your URL to a resource, you know, probably on your server or somewhere on the internet that you want to download. And you simply ask the session, I'd like a download task with this URL.

And you get back a task object that represents the state of that transfer happening in a background daemon. Now these transfers are created paused by default. So when you get this task operation back, in order to actually start the transfer, you simply call resume on it. And now the background demon will start downloading your content.

Now these task objects support all of the typical things that you would find in a network transfer operation. You can suspend them, you can resume them, you can cancel them, right? Those are the typical things. And these task objects are what you would use if you were to build a user interface around these operations, right? So if you want to present to the user the status of these transfers, these are the objects you would center that around.

And I mentioned when the transfers are completed, there's a new UI application delegate method that will be invoked that you provide. And it's a callback that basically says you need to handle some events in this background session. And you're past a completion handler, and I'll talk a little bit more about the completion handler in a second.

When you implement these methods, the common thing to see is you reestablish your connection to the session object, you get the list of tasks that have been completed, and then you handle the results. If you've downloaded something, you unpack the contents and you save it. If you were uploading something, maybe you just let the user know that your upload has been finished. And I should mention everywhere in this section that I talk about downloading, you can replace that with upload, and it's all the same. So this is up for uploading and downloading.

Now there's a couple considerations that you need to keep in mind when you're implementing this new UI application delegate method. And the first is that if you're running in the background, if we're notifying you when you're in the background, you only have a short amount of time to run. And by short, I mean on the order of seconds as opposed to minutes. You can see how much time you have remaining by inspecting this background time remaining property on UI application.

And that completion handler that I mentioned that was called into this new delegate method, you need to call that when you're done processing the results of this download or this transfer. If you don't call it, then iOS will terminate your app. We need to hear back from you when you are done. And you want to call it as soon as possible. So you want to do as little work as possible, be finished, and then call the completion handler.

And then this next item is extremely important, and I'm going to repeat it a few times throughout the remainder of this presentation. You need to be aware of data protection. And if you have not come across data protection, or if you haven't looked into it, or haven't had a need for it yet, as you adopt these new APIs, it's critical that you understand how it works and what it means to your application.

Not only will your app potentially be running in the background, where it may be the first time you're running in the background, you may also be running when the device is locked. And when the device is locked, if there is a passcode, that means that data protection is going to be enforced. And when data protection is in effect, some things like keychain items or files on disk may not be accessible by your app.

And you need to understand what the ramifications of that are and how to deal with it. Now, our next session on security and privacy is going to go into more details about data protection, so I'll leave the details to that. But just for this point, just be aware that you need to understand data protection and what it means to your app.

So now you're done downloading stuff, and now the question is, what do you do with it? So you're invoked in the background, and you need to save this data somewhere. And SURL session itself is only going to hang on to the downloaded contents temporarily, up until the point you call that completion handler.

So if you want to store this data that you downloaded for an extended period of time, which you probably do, at least in this example of separating assets out of your app bundle, you need to move it somewhere, and you would put it in your app sandbox somewhere.

It's critical here that you pay attention to the iOS data storage guidelines. Now, if you've never read these guidelines, you definitely want to go do that. What they tell you are the places on disk where it's appropriate for you to store things, right? What types of files should go in the temporary directory, in the app support directory, in documents, and things like that. So it just kind of lays out where you should put things. It also documents what files will be by default included in a user's backup.

Paul Marcos Especially the user's iCloud backup. And it's really important that you are aware of those and adhere to these guidelines because the app review team is applying these guidelines and they're enforcing them when they review your app. And this is a really common reason that developers get rejected is because you have files in a place that are included in an iCloud backup that they don't need to be. So you want to read these guidelines. If you do have files that you're storing somewhere that don't need to be included, you want to read these guidelines. Paul Marcos So this is a very simple API on the NSURL where you save the files.

Just simply call set resource value for key, specifying this key that indicates this file should not be included in the background. So really easy and that will help you get through the review process with no problems. So that's the third item in this checklist for minimizing install time. And that's, like I said, these first two items of just making sure you clean things up, use compression, those are the best practices. And those apply to everybody, no matter what kind of app you're developing.

And then the third thing, considering breaking things up. You might look at using NSURLSession to do the background uploads and downloads. And NSURLSession really is the future of foundation networking. This is a fundamental shift in how you should be writing your networking code. And you want to be adopting it now.

Eventually, NSURLs connection will go away in favor of NSURL connection. So, you know, jump on the bandwagon now, and that'll serve you well in the future. And then lastly, pay attention to the iOS data storage guidelines for a great app review experience. So that's background transfers and how you can use new I/O 7 technology to minimize your install time. Next up, I want to talk about multitasking, which John talked a little bit about this morning.

And in iOS 7, obviously you're all familiar with the new multitasking interface where users can see a snapshot of your app even when it's not running. This gives people great insight into the state of your app. And this is the experience that I want to talk about how you can enhance it.

And the enhancement really comes around keeping these snapshots alive, right? Keeping them up to date over time and giving this, your application the impression that it is running all the time and it's always up to date. And most importantly, like John talked about, that your app is always ready, right? That's one of the things that will really differentiate a great app from just a good app. So a couple examples, you know, you might have a chat or a messaging app.

Where push notifications are coming in and in response to those push notifications, you know, yeah, the user sees them in notification center, but maybe they're busy and they ignore them and then kind of forget what was there. Well, with these new multitasking APIs, you can update your snapshot and reflect the new messages, right? Update the chat transcript so that they see in the switcher that there's new content there.

Or another example, so many apps have social network feeds in them, right? And over the period of a day as the user is using their device, they may not be going into your app, but these new APIs give you a hook where you can periodically update that app snapshot with new content from people's social feed. So a couple really great ways to keep these snapshots alive. So let me talk a little bit about where these snapshots come from and then what the new opportunities are.

Paul Marcos So the typical sequence would look like this. Someone launches your application, and as part of your launch or your activation, you're going to go fetch new content from your server, from social networks. Paul Marcos You'll update your internal state, and then you'll update the state of the UI.

You'll show the new messages or new feed contents. Paul Marcos Then they'll use your app, and at some point they'll hit the home button and they'll leave the app, at which point your app will get suspended. Paul Marcos And that's when iOS will take a snap. of your app.

Now this flow is obviously user driven, right? It's based on user activity. And what's new in iOS 7 is we have a couple new entry points into the same flow that ultimately lead to you being able to update your snapshot. And these are driven by iOS and they're actually new background modes. There's two of them, remote notification and background fetch.

Both of these can be configured in Xcode's capabilities panel. They are, as I said, new background modes that are shown here down at the bottom of the list. And the key thing to point out here is that these new background modes are available to all apps. If you look at the list of background modes we had previously, they were fairly specific in use and purpose, just for updating location in the background, or a voice over IP app. Or playing audio, or using AirPlay in the background.

And your app had to do that specific function in order to use the background mode. But these new background modes are available to all apps. And because they're driven or initiated by iOS, we can do so in a power smart way. So we can ensure that people's batteries aren't going to be drained.

So let me go through both of these new background modes and give just an overview of how they work and what you can do with them. So starting with remote notifications, really all this means is that you can send push notifications to your app and they'll now be delivered regardless of whether the app is in the front or not. They'll be delivered to your app even if you're in the background.

You might want to update your social network feed periodically throughout the day. And after doing this background fetch, that's your opportunity for updating the app snapshot. Now, as I mentioned, both of these new things are really initiated by iOS. And in the background fetch case, we'll take two things into consideration.

One is, we'll base it on previous usage of your app. So we're kind of looking out for patterns that people use your app throughout the course of a day. And let's say you have an app. There's a bunch of games that I'll play in the morning before I go to work and then in the evening after I'm out of work. And I'll be at home. And iOS will notice that, oh, these apps get launched in the morning and the evening.

And after a little while, we'll start seeing that pattern. And what iOS will do is launch your app, launch those games just a little bit before we think the user's going to go into the game. So it gives you an opportunity to get up to date before the user is there so that when they do launch your app, you have the latest information and you feel like you're always up to date.

Now when you're updating your content, just like the background transfers, you want to call the completion handler as soon as possible. If you don't call it soon enough within the amount of time you have to run in the background, iOS will terminate your app. And that's very similar to if you don't suspend or resume or launch quickly enough, iOS will terminate the app.

So in order to avoid being terminated, you want to keep your fetches as small as possible. Fetch just the metadata that you need to update the UI. If you do realize that there is new data that you do want to download, you know, maybe there's new pictures available in someone's social feed, there's a new file available that you want to download, that's a great use for the background transfer service. So you can use some of these new technologies really in conjunction with each other. So use the background fetch to know when there's new stuff and then queue up a background download to go get it.

And if your app uses OpenGL, you may be thinking, well, I'm not allowed to draw using OpenGL when my app is in the background. And so we've also changed this a little bit. During the time when we call the UI application delegate method, between that time and when you call the completion handler, you can use OpenGL even if you're in the background.

Now, you want to be as efficient as possible. And if you can get away with rendering a single frame, you know, that would be great. So do that. You know, just render a single frame, update the UI, and we'll take a snapshot of that. But you can use OpenGL in the background during these delegate callbacks.

And just like before, be aware of data protection. Now, this is an interesting case where you may be getting launched to do a background fetch. And just by the very nature of fetching things, you probably are going to need to check in with your server. And you may need credentials to do that. And by default, credentials in the key chain are going to not be available if the device is locked.

So we have seen this trip up some developers already, where they've tried to get the credentials. They've failed. Maybe didn't have the error checking around that that they should have. Then went and tried to log into their server. And that obviously failed, because they don't have the credentials. And then they got into a kind of a confused state where they thought, oh, the authentication failed.

The password's bad. We'll log the user out. So we've just seen some confusion around this. And that tells me that maybe people aren't paying as much attention to data protection as they should. And that's why I'm here pleading to you to make sure that you understand data protection and what it means to your app.

So that's multitasking. It's new APIs that let you keep your apps up to date. And most importantly, keep these app snapshots up to date. Remote notifications let you get your push notifications, even in the background. And now you can send silent notifications, background fetching, new opportunities to update your content before the user needs it, to really let them feel like your app is always ready.

And again, I promise, I think this is the last time I'll say this this session, be aware of using data protection when the-- or be aware of when the device is locked using data protection. So that's some new multitasking APIs in iOS 7. Now lastly, let me move on to iBeacon, probably our most interesting new technology that I'm talking about here, certainly.

So what is iBeacon? So very simply put, iBeacon is a Bluetooth low energy device that is simply emitting a signal, a unidirectional signal that's being emitted. And in that signal is an identifier. And what that enables is it lets an iOS device detect when it's near an iBeacon. And when it detects that, it can actually respond to it. And most importantly, it can notify an app that the device is now near an iBeacon.

Now, there's a couple of new APIs that we have, or a couple APIs you use to integrate with iBeacon. The first is region monitoring. That's actually an existing API. And then the second is ranging. And that's a new set of APIs. So let me go through both of these to explain what they are.

Now, region monitoring, as I mentioned, it uses the same core location APIs that we've had actually for a good number of releases, I think back to iOS 4. And we use those APIs for doing geofencing, right, for doing notifications of when a device moves into or out of a geographic area.

Now those are great APIs, and we're using the same API for doing beacon regions, what we call beacon regions, an area defined around an iBeacon. But iBeacons are much more flexible because they're not tied to a specific place on the planet. They're typically battery operated, so you can attach them to things that move around, and that really enables some very interesting location awareness in apps. You could put them on a subway, on a train, or a bus, or something like that, and now an app can detect when it's near a bus or a train has pulled into the station.

You could put them on a cruise ship. Cruise ships moving around the planet all the time. And it's also made up of levels, which is kind of interesting. That's a challenge for geofencing because that tends to be just a single point. So you could put iBeacons in different places on the ship and do a lot of interesting things with an app that users use on a ship. Or, you know, for more accurate indoor location.

We just recently rolled this out in a lot of our Apple retail stores. So iBeacons can really enable more accurate detection of location indoors where GPS signals have a very hard time penetrating. So another place that we use this in iOS is in Passbook. So to make a pass relevant on the lock screen, you could specify a latitude and longitude.

And now in iOS 7, you can specify a pass. So iBeacons can really enable more accurate detection of location indoors where GPS signals have a very hard time penetrating. So another place that we use this in iOS is in Passbook. a beacon. And we actually did that -- we're doing that for the tech talks. This morning, we had an eye beacon on the registration table. So, as you walked up to the registration table, if you saw the pass on your lock screen, that was because it detected that eye beacon sitting there.

So that's the region monitoring APIs, based on the same APIs we had before, just with a new way of triggering the notifications. Now, the new APIs in iOS 7 are around ranging. And what ranging is, is it's a set of APIs that will give you an estimated proximity to a beacon. And we categorize this proximity into three zones, right? Immediate, near, and far. And let me talk through each of these and explain what they are.

The immediate zone is reported when a device is really right up next to an iBeacon, measured probably on the order of centimeters. It probably represents, if for example the corner of this table was a beacon, it probably represents a user actually taking a very intentional action of holding their device up to the beacon.

Paul Marcos And because we're so close to the beacon, the signal strength from the beacon is very strong. And all the detection of iBeacons is based on signal strength. And when we have a very strong signal strength, we can be very confident of the distance to that beacon.

Moving further out from there is the near zone. That's probably on the order of a few meters. We probably still have a good signal strength, so we have reasonable confidence on the accuracy of that proximity. That might be here in this immediate area, the first few rows or so. And then going beyond that is what we call the far zone. And that's more than a few meters, kind of on up towards the edge of the Bluetooth signal.

This whole notion of signal strength and the accuracy and the proximity is really the important part that I want to focus on here today. In order to understand the importance in how the signal strength affects the accuracy, I want to draw a parallel to how GPS works in Maps. So here's the Maps app. And you're probably all familiar with your location in the middle with this blue circle around it, which represents the margin of error that we have around our confidence of where you actually are.

So the accuracy with iBeacons is just like with GPS. When we have a weak signal, when the signal from the satellites or from an iBeacon are weak, we have a high margin of error, just meaning that we can't be confident about specifically where you are. In maps, that's represented by, you know, a fairly large blue circle on the order of a kilometer or so.

Now, as the signal from the satellites improves, maybe the device was indoors in this example and now it's kind of moved outdoors, that blue circle will shrink down because we have a stronger signal. And now we can kind of say, well, we know we can shrink this area and say you're in a smaller circle.

And then when we finally get a really strong signal and we have a direct line of sight to the satellites, you know, that blue circle goes away altogether and now we say, okay, we know where you are. You're right here. Now this idea of accuracy and this kind of concept of this blue circle is really the same for iBeacons. Now iBeacons have an accuracy. And what that is when you're looking at this in code is it's our guess as to how far away from the iBeacon you may be.

So it's our estimate of the distance. And it is just an estimate. And if you're really into statistics, I'm going to be very specific here for a second, it's actually a one sigma estimate. So if that means anything to the statistics folks in the crowd. And if you take that estimate and you were to double it, then that raises the question, it raises our confidence to 95%.

We are 95% sure that you are within that distance from the beacon. So that's just my little side spiel on the accuracy going into statistics. Now the thing that affects signal strength the most is, or sorry, the importance of the signal strength has to do with signal attenuation and things that affect the signal strength and minimize it especially.

So now Bluetooth, this is all based on Bluetooth technology. So Bluetooth uses the 2.4 gigahertz frequency for sending signals. And that frequency range is, you know, it's affected by physical objects, by, you know, desks or walls or doors, things like that. And that can affect the signal strength. It can reduce the signal strength, which minimizes the signal that we receive, thereby affecting our confidence in the accuracy.

Now this 2.4 gigahertz frequency is also affected by water, it turns out. And since our bodies are mostly made up of water, this can really have an effect on the accuracy when you're using iBeacons. And this is an important thing to keep in mind as you're deploying iBeacons.

So, you know, if you have an app that is using iBeacons and your user actually has their device like in their pocket or it's in a purse and it's being held up against their body, then their body may actually be affecting the signal strength, depending where the beacon is located.

Again, if it's on the corner of that table, if I have the signal or my phone in my pocket and I'm facing it, that might be one thing. But if I've turned around and now it, you know, is blocked by my leg or by my body, that can reduce the signal strength. and that affects the accuracy that we have.

As a result, when the signal strength is decreased, that may cause us to think that an iBeacon is actually in the far zone when it may actually be near. So this is just an important thing to consider as you're deploying it, and I'll talk about some deployment considerations in a little bit.

Paul Marcos But this signal attenuation and signal strength is probably the most important thing for you to understand. There's a couple best practices that we've come up with for using these new ranging APIs. Paul Marcos Now, the first is the ranging APIs are really intended to be used interactively, meaning not while the device is locked and in a pocket or in a purse or something like that.

Paul Marcos You're going to get the best results when the user has their device out and it's in their hand, your app is front most, and they're actually interacting. Paul Marcos Because that's where the antennas are probably not blocked by anything, and it's your best chance for getting a line of sight to the beacon. Paul Marcos And that's when you get your best results, is when a device has clear line of sight not blocked by physical objects or other human bodies.

Now when CoreLocation reports to you what beacons it sees, you know, if you're using just a single beacon, then things are pretty clear. You just get your proximity zone and you determine what to do at that point. But if you're in a situation like imagine a retail store where you may have multiple beacons for different departments or whatnot, CoreLocation is actually going to return these beacons sorted by our best guess as to the proximity.

So we'll try to put the closest one first. But it's really important that you are flexible if you're ranging to multiple beacons and all of them are reporting they're in the far zone. You want to be flexible with that. You may build a user interface where you present to the user, well, here are the beacons that we see, but we don't know exactly which one is closest. So we're going to let you pick.

Let the user have kind of some involvement into the interaction here. Now, if you see immediate or maybe even near, you may want to lock in on that because our confidence is higher. But with the beacons in the far zone, maybe, you know, just show the user what they are. Let them kind of drive the engagement.

Now, calibration is a really important thing. And it's crucial for you to calibrate the experience and the beacons in as close to the environment, if not the actual environment, that you plan to deploy them. You need to consider the placement of beacons, where they are. Are you mounting them under a table, behind a sign? Or can you mount them kind of in the clear? Are they above people's heads or not? Paul Marcos And you also want to test and calibrate with the expected number of people in the environment.

Because the signals are affected by the human body, you want to make sure that you have the estimated number of people in the environment. Paul Marcos And then once you've done that, you want to see what the results are like. Are you getting immediate and near proximities? Or do you only see far? If you only see far, then maybe you need to consider deploying more beacons. And then you want to pull up on the beacons that you have, just to increase the likelihood that the device will get a strong signal.

Now one thing to consider is that iOS devices themselves can be beacons. Any Bluetooth low energy enabled iOS device can be turned into a beacon. An app can request it begin broadcasting a beacon signal. There's a bunch of examples that this makes sense in, you know, point of sale apps or really any type of app that is in a single purpose like a kiosk mode is one way of looking at it. That's a great candidate for using the iOS device as a beacon.

But there's a big caveat that comes with this, and this is one of the most common questions I get. The app has to be frontmost and the device needs to be unlocked, right? You can't be broadcasting, an app cannot request a device broadcast as an iBeacon when it's in the background. So if you need that, then you might want to be looking at battery powered iBeacons when they're available. So that's just a summary on iBeacon.

Paul Marcos New Bluetooth technology that enables region monitoring and proximity detection. These are great for mobile objects or indoor use cases. You need to pay attention to the accuracy and the signal strength in real world environments. You want to calibrate and test in these real world scenarios to ensure the best user experience.

So that's the three technologies I wanted to go through. Background transfer and minimizing install time, multitasking and keeping your app snapshots up to date, and then iBeacon for providing an entire new class of location aware apps. So if you have any questions, here's my contact information. I'll be in the labs immediately following this session.

And then at the reception in the afternoon, we've got some documentation online. There's a very active core location forum on our developer forum. So I encourage you to participate in those discussions. And then in addition to that, we talked a lot about all of these new technologies at WWDC this past year.

And obviously, I've just scratched the surface on all of these. So definitely check out these videos. What's New in Foundation Networking went into NSURL session and all of the functionality that is offered there. What's New in Multitasking went through the remote notifications and background fetch. And then two sessions talked about iBeacons. One was What's New in Core Location, which went through the new APIs.

And then this last one, Harnessing iOS to Create Magic in Your Apps, was actually a session given by the Apple retail store engineering team, talking about how you might use iBeacon. And they had given an example of using it in a museum for interactive exhibit information. So thank you very much.