Good morning. My name is Brian Tucker and I am a manager in our Wireless Software Engineering group. Fundamentally, I'm responsible pretty much for all Bluetooth technologies on iOS platforms. So this is CoreBluetooth 101. This is not basket weaving, so if you are looking for that, you are in the wrong room. CoreBluetooth 101 primarily is an API that focuses on Bluetooth Low Energy, which is a new technology that was ratified by the Bluetooth standards body. I believe at the end of 2010, it was introduced in our products last year with the iOS 5 and with the iPhone 4S.

And why do we think it's important to talk about this technology with app developers? Well, I think that Low Energy, in the sense of Low Energy, if you look at it from a technology perspective, really applies to every single person in this room as a consumer, but especially as a technologist. I'll give you an example.

I was in China earlier this year and I had the opportunity to speak on this topic in China and it was in front of about 2,000 people. And in China, of course, you have translators. And I had never spoken to a group of people with translators before. And they were sitting over there in this booth and they had put somebody in the front row to tell me when to slow down.

Because like when you speak too fast, the translator is going to slow down. And when you speak too fast, the translators are like machine guns. You know, this stuff is just flying out of their mouth, right? So they had this guy in the front. He was flashing this flashlight at me and he'd flash the flashlight when I was talking too fast, right? So I'm watching my timer here and I know how many slides I have left and I realize there's no way I'm going to get through the slides, right? So I look at him and he kind of looks at me and we have this Western showdown thing and he realizes I'm not going to slow down, right? So at any moment, I'm going to slow down. At any moment, I'm pretty sure he's going to throw the flashlight at me.

But we get through it. I get done on time. All the slides got done. I'm sure the, you know, the translators are ready to shoot me. And so I walk down the stage and I see the translator running across the stage at me. And I'm like, here it is.

I'm going to get killed by this translator guy, you know. And he comes up to me and he says, that was amazing. You know, and I'm like, what? And he's like, you know, I never talked that fast in my life. No. And he said, I'm going to go home today and start working on this technology. And I was like, wow, okay. I didn't expect that, you know. So it really does apply to everyone. And so that's why we're really excited about it.

So the topics in this session are threefold. So we have Bluetooth 4.0 low energy. So this is kind of a 101 of Bluetooth low energy. Hopefully, you'll come away from this having at least some semblance of what low energy can do. Right? Then we'll talk about core Bluetooth. Now, core Bluetooth is our framework.

And if you don't know what core Bluetooth is, hopefully by the end of this, you'll at least have some idea. And then Joachim will go into this in a lot more detail after lunch. And then we'll actually give you a demo. So we'll demo one of the sample apps that we actually have up on the developer site. All right.

So let's get busy. Bluetooth 4.0 low energy. So I want you guys to consider this as kind of your BTLE 101 class. There will be a diploma at the end of it. So stay through the whole session and you'll be able to go make money on this. No, seriously. So some key concepts that we'll be learning here. Things like advertising, concepts like device discovery, connection management, what a service is, what a characteristic is. All that stuff we'll cover in the next 20 or 30 minutes.

So what's the big idea with Bluetooth Low Energy? Well, most of you can probably guess that the big idea with Bluetooth Low Energy is this guy. It's the 2032. So for those of you that don't know what this is, this is your standard coin cell battery. Works off of three volts. They come in different capacities. And the idea is that we can now make accessories. We can now make products.

Don't even call them accessories. But we can make stuff that runs on a really, really cheap, low energy or low power source battery. And the iOS device can talk to it, can have a conversation, and it can provide information. And you're like, okay, well, that's kind of cool. But what does it really mean? What does it give to the consumer, right? What's the big idea? Well, we do it through three ways.

And it's really not rocket science here, so don't expect any miracles. But the first one is obviously we spend less time in the air. We spend less time communicating between the two devices. That's pretty obvious, right? Well, in addition to that, we send less data. So anybody that's expecting to do gigabit data rates on LE, again, you can go find another session because you're not going to do that in Bluetooth 3. And that's not its intention, right? Bluetooth LE is intended for very low power. Remember, we're going back to that coin cell. And the coin cell is not going to last more than a day if you're constantly sending data over and over and over again.

And finally, really, LE is a whole new architecture. So some people have asked me, well, why can't I do LE on an iPhone 4? Why can't I do LE on the old iPads? And there really is a difference at the fundamental level. This is a different at the fundamental level of the baseband itself, of the radio, right, and the filer. The timing is different. The relationship between Bluetooth LE and classic Bluetooth or basic rate, enhanced data rate completely changes.

So with these three models, we've defined this kind of concept of Bluetooth Low Energy. So let's compare it with what we expect with classic Bluetooth. So this is a chart, albeit simple, but a chart that shows you how much energy, per se, does it take to send an 8-byte packet.

And it's quite a bit of savings. It's not quite 10x, but it's pretty good. Now, it doesn't necessarily always have to be like this. As we see generational steps in Bluetooth Low Energy devices, we're seeing improvements in this, actually. And this is getting better and better every day. Sensitivity is going up. The amount of power used to send traffic is going down. The devices are getting smaller, all that kind of stuff. Efficiency is improving.

But if we compare this against actual data rates, you can see that, well, you can't send very much data on LE, all right? So you have to have a real expectation. And in reality, this is theoretical. If we take the actual, the real data, it's actually much lower. So in reality, you're going to see about a 50 kbps data rate with Bluetooth Low Energy. And that's really pushing it. That's downhill with a stiff wind falling off a cliff.

Now, that's not easy. And Bluetooth, we put 1200 there. It could be better. It could be -- we've seen 1700. Gus will argue that we've seen better. But 1200 is pretty realistic. So you're just not going to get a lot of data through LE. So is that clear, hopefully? I get that a lot. All right.

So before we get into how it works, I thought it would be really useful -- to maybe give you guys some use cases on why we think LE is so exciting. And remember I said at the beginning that LE really does apply to everyone. And I truly, honestly believe that.

There's this concept that's lived, you know, in academic fields and in certain industrial fields, this concept of the Internet of Things, right? This concept that you have this cloud of technology around you or this cloud of devices around you, and your device can start interacting with those devices, right? Well, we think LE really does enable that, right? Now, other radios to a certain extent do it as well, but LE really, really does.

It's simple. It's easy to use. It's low power, right? So let's go through some of these use cases. So the first one, and the one that I think is really exciting, is health care. And health care and exciting, I know that's kind of weird, but health care is hugely useful.

It's a really good example for Bluetooth Low Energy. In fact, the Continua Healthcare Alliance, which is a consortium of companies that have come together to kind of create standards around health care, they've actually standardized around Bluetooth LE. So that means, like, when you go to the hospital and they have, like, an EKG system, or they're monitoring your heart rate, or they're measuring your blood levels or whatever, all of those probes on your body can all be LE and wireless, right? And it just goes on and on and on.

Stethoscopes, blood pressure cuffs, I mean, everything can be wireless now because they can make a device that runs off a battery that can literally live on that battery for months, and in some cases even years, right? So another use case that's really close to health care, but it's not really health care, is sports and fitness. And this is an obvious low-hanging fruit for Bluetooth Low Energy. We're already seeing products that use LE in this space today.

In fact, the heart rate monitor. And there's a few companies, Wahoo has one, Polar has one that just came out. In fact, my shoes right now have LE sensors in them made by Nike. So it's starting to become really, really active in the sports and fitness, and given the kind of conversations we've had with companies, it's just going to get bigger.

Security. So most people don't think about this, but consider your phone as the key to your car or to your office or to your home, right? With LE and the fact it's using AES-128 and you can create an encryption link and you can do a defined key model sharing between these two devices, it's really, really useful in security applications.

automation, and in this case, home automation. Now, I realize there's a lot of different competing technologies in this space. Smart energy seems to be focused more on things like ZigBee and some of these other technologies, and those are great, but Ellie clearly has a practical use case in home automation, and more specifically, if I, you know, what's the one thing you always have, right? I have it in my back pocket right now.

It's your phone. It's your iPhone, so as you're walking around the house and I walk into a room, well, that room knows what I like, right? It knows what the temperature should be. It knows what the light should be, right? It knows what the ceiling fan should be on or not. I mean, there's a lot of automation, and that's just really simple stuff, right? So home automation.

And then something very closely related to that is home entertainment, right? And this is another really obvious one, but I think it's super exciting, is that now your iPhone, and not necessarily just your iPhone, but your remote control can have a two-way conversation with the entertainment devices in your home.

Craigdooley, Brian Tucker So if I go to Amazon and I buy my new Blu-ray player or whatever, or my Apple TV, which is more appropriate, it might have a conversation with those two devices, right? It might immediately know, "Oh, you just bought a Blu-ray player, so clearly you can hit play," you know? And it can even go beyond that. And the Blu-ray itself could provide information to the iOS device, and it's just -- the sky's the limit when it comes to LE and home entertainment.

Craigdooley, Brian Tucker The devices can talk to each other, you know? Craigdooley, Brian Tucker So again, start thinking about it as it relates to doing the same thing you're doing over a wire, at least from a command and control perspective, over the wireless link, right? Toys. So as a father of two young kids, this is huge for me, right? And the reason I have children, at least my wife would say, is so that I can play with their toys. And it's awesome, right? So with LE, it just -- the sky's the limit.

I mean, think about the fact that you can go buy a toy, and my kids already love the iPad. So now the iPad extends to the toy. And it's like it's a robot, so they can program the robot to do a bunch of things. Or it's an interactive board game that ties the board game directly with the iPad, right? And they can do it, and you guys can do it at a cost that makes sense to the consumer. It's not like they're having to go out and spend $200 for a board game. You know, the costs of these products are actually getting lower and lower, and LE is a huge part of that. Pay systems.

So obviously there's other technologies that resolve around pay systems and NFC clearly is one of them, but I would argue that LE is actually really, really good for this. It's secure, it's localized, it's easy to use. Some fundamental things can happen around LE and pay. Time. So with time services, what do I mean by that? Well, if you look around you, there's clocks everywhere. There's clocks in your car. There's clocks on your microwave. There's clocks in your home entertainment system. There's your alarm clock in your bedroom. Some of you may even have VCRs. If you do, you need help, but it may be, you know, flashing a 12 on that thing.

Think about your phone. Your phone always knows what time it is. So as a time service model, you can walk around your entire space and be completely syncing all of your time, right? You go to a new place, you walk into a hotel room, the clock on the hotel room is wrong, it instantly goes to the time that you care about, right? Time services. Doesn't sound like it's too exciting, but for me, I would love it.

Craig Dooley, Brian Tucker What do I mean by proximity? Well, radio models are somewhat good at determining distance, right? And we can do it through the calculation of the propagation of the signal across air, and we know the signal level of the receiver and the transmit output power of the devices, and we won't get into all that, but the idea is that we can determine that something else is near me, right? So when I walked into that room and knows I'm in the room, when I walk up next to my car, my car just unlocks, right? And it's based on security and proximity. There's a ton of stuff you can do with proximity. In fact, in the Advanced Core Bluetooth session, we have a demo that's really cool that Krav put together that does proximity, and I won't spoil the fun.

It's really cool. So that's some of the use cases around Bluetooth LE, and there's a bajillion more than this, but hopefully you'll be able to see some of the use cases around Bluetooth LE. So that's some of the use cases around Bluetooth LE, and there's a bajillion more than this, but hopefully this kind of whets your whistle, and it really gives you some ideas.

Oh, wow, LE really is useful. There's really some interesting use cases for this. Okay, enough of that. So let's get into some key terms. The first one is this concept of dual mode and single mode. So what does this mean? Dual mode is probably most of the devices you are using right now.

I'm assuming all of you went out and bought the new MacBook Pro, MacBook Air, I doubt you have Macminis, or an iPhone. Those are all dual mode. They can do both classic Bluetooth and they can do Bluetooth Low Energy, right? Well, a single mode device is exactly that. It does one thing, and in the case of this topic, it does Low Energy. That's all it does. And so you will start to see more single mode devices that can interact with dual mode devices.

And single mode devices can actually interact with other single mode devices as well. But as you see this described in the spec and you see it described in our documentation, this will become -- hopefully now you understand what that means. So another key concept is nothing that should be new to anybody in this room, CES 101, but

The concept here is the server has some data. Let's use the heart rate monitor as an example. So the heart rate monitor has my heart rate strapped to my chest right now. It's probably running at 120 beats a minute.

: I'm going to die. The client wants that data. So my phone wants to know what I'm doing. Right? So this is a really basic concept. So if we look at this as it relates to the Bluetooth definition of this, you have this concept called peripheral and this concept called central. I didn't make up these names. This is not something I did. Central, not sure I like the name, but we're stuck with it.

That's in the spec. So as you would imagine, these are the devices that would be a central or a peripheral.

So to make it a little bit more real, I thought it would be useful to explain to you that this is actually what's happening is that your peripheral is actually advertising on multiple frequencies. There's actually 40 frequencies within the Bluetooth LE spectrum, 2 megahertz wide, and within those intervals we have these three advertising channels. And what's happening is that that device is broadcasting on channel 37, 38, 39 with a little gap in between.

So what's happening is the scanner, the observer, the iPhone in this case, is listening on one channel, and we see that packet. And then it's doing it again, advertising on three packets, and we're scanning on that channel, and we're listening on that packet. So it's really, really important for your accessories to be using all of your advertising channels.

Really, really important for discovery time. And guess what? There's that advertising interval again, right? And the advertising interval, hopefully you can start to see why advertising interval is directly related to how quickly your app can discover a Bluetooth LE accessory, right? All right, so let's talk about setting up the connection.

So now that we've discovered the device, now that we know it's out there, my heart rate monitor is advertising, my phone wants to talk to it, what happens? Well, it's advertising, we're scanning, we see that device, it's really simple. All we do is we turn that around and we send a connection interval. I'm sorry, a connection request. And the connection request goes back to the accessory, it accepts, and something magical happens. These two devices now become central and peripheral.

The peripheral is the device that was advertising, and the central is the device that wants to talk to that advertising peripheral, okay? And at this point, they're just going to start exchanging data. Pretty basic, okay? Now, if we look at how we send data, there's another key term here that you guys should burn in your brain, and that's connection interval. So if we look at how these devices are communicating, the central says, hey, do you have any data in the peripheral? And the peripheral says, yep, here's some data.

And then again, hey, do you have any data? Yep, here's some data. Do you have any data? Yep, here's some data. And if it doesn't have any data, it says, nope, I don't have any. And it's actually a little bit more complicated than that, but you get the concept.

Now guess what? That connection interval is the interval at which you can send one set of data and then send the next set of data and then send the next set of data, right? And the reason it does this is because it can't just constantly be transmitting. Again, we go back to the original idea and that was the coin cell battery, right? So if we have to have an interval to how we communicate because, again, we're trying to save power, the connection interval, guess what, directly ties to how fast you can send the data, right? Because we can't send a whole lot of data in one particular packet. Let's just say it's, you know, 20 or so bytes.

Now you can start to see why LE is not designed for high bandwidth, okay? Now you can send multiple sets of data within a single connection interval. In this case, I sent two. And that just can continue within that connection interval. But again, this directly ties to your battery life. I think I've harped on that enough. Topology. So let's talk about topology for a minute.

So two key concepts. The first is this concept of advertising, okay? So the advertiser, the broadcaster can advertise to multiple observers. So if I had my heart rate monitor belt on right now, every single one in this room could see all that advertising. If, for example, somewhere on the wall is a thermostat and it advertises temperature, every single one in this room could see all that advertising.

If, for example, somewhere on the wall is a thermostat and it advertises temperature, every single one in this room could see all that advertising. Everybody in this room would know what the temperature of the room is, right? Some really powerful things can happen with this kind of topology.

A plant soil moisture device in my backyard could be broadcasting a little bit of information in the advertising packet that tells every device in my home what's going on, right? A plant soil moisture device in my backyard could be broadcasting a little bit of information in the advertising packet that tells every device in my home what's going on, right? So that's that topology.

And then once we're connected, a peripheral can only be connected to one central. Now, a central can be connected to multiple peripherals, and certainly we allow that within iOS. And then one exception to this is that, in iOS at least, you can have multiple centrals connected to your peripheral. We don't make that limitation within our product.

So that's topology. So what's the data look like? How do we exchange information? Well, two main concepts-- services and characteristics. Services are a description of the set of data. So pull out your XML hat for a minute and think of it in terms of this tree. So if we have this definition of a server, and we have this service within that server, and we're going to call it our heart rate monitor.

So this polar belt has this definition of information. And there's a standard for this, actually, that's in the Bluetooth standards body on how to do this. But this service is called heart rate monitor. Well, there could be multiple characteristics that relate to that service. And in this case, we have two. And there's more than that. But in this case, there's two. The first one is pretty obvious-- my heart rate.

But the next one might be less than obvious, but really useful is where is it? Is it on my wrist? Is it on my chest? Is it on my neck? And that may change the telemetry aspects of the data recording for heart rate, especially in healthcare. So that's kind of the basics of a server and characteristics. So let's tear down a characteristic. What does that consist of? So the first thing is the type. Now, this is a key point. It has a UUID, or Universal Unique Identifier.

Everything in LE, everything in CoreBluetooth is based on UUIDs. And Joachim will go into more detail on exactly how to generate them and why they're important and what's the difference between a Bluetooth standard UUID versus one that you generate. One is 16-bit, one is 128-bit, that kind of stuff. But this identifies this characteristic. Second is value.

Now, we don't type the value. We don't say this is a string or this is a byte or an integer or whatever. It's just a blob to us. We take it from the server and we hand it to the app. Right? We take it from the app and we hand it to the accessory.

Right? There's some properties about the characteristic. Can we read to it? Or can we read from it? Can we write to it? Can this support notifications? Notifications are kind of cool because what you can do in Client Config is you can turn on notifications for characteristics that support it. And the server will automatically feed you updates. So you don't have to keep saying, "Do you have any data? Yeah? Do you have any data? Yeah?" You know, it's more efficient.

And then finally, there's descriptors or additional descriptors, and it's completely up to you. Keep in mind that LE is loosely defined as it relates to a set of standards or profiles. Much unlike Bluetooth in general. And you can go and completely define your own implementation of LE. These shoes, for example, aren't using standard profiles. But the heart rate belt is.

And with your app in iOS, you can do either. So remember when I said it's kind of like a tree? So this is just a visual representation of that. My peripheral can have multiple services, and my services can have multiple characteristics. It's really, really basic. All right? So that gives you a sense of how this works.

So hopefully that was a whirlwind tour of Bluetooth LE. And there's a whole lot more about this technology. If you are having sleep problems, go and get the spec. Read it for about 10 minutes and then you'll be asleep. But everything I talked about is in the Bluetooth 4.0 core spec. Pretty much everything you need to know is in there. But good luck.

All right, so let's get into core Bluetooth. CoreBluetooth is the representation of LE on our iOS platforms. It's the framework that you use in your apps to talk to accessories and to host peripherals, right? We have three primary core principles. So the first one is we want it to be simple.

So when we started writing this, we probably rewrote it I don't know how many times. We kept realizing it's too complicated. It's too complicated. It's too many objects, too many variables, too many interfaces. So we kept fighting on ourselves to make this simple, to make this easy to approach. But at the same time, we didn't want to limit you in what you could do. We didn't want you to go, ah, this is a baby framework. Nobody can use this. So we wanted it to be really, really powerful.

That was really hard. So hopefully what we have in Core Bluetooth has done that. Some people would argue that we have. Some would say we haven't. But we feel like that it's the great intersection between being both powerful, giving you the features that you need, but at the same time not requiring you to get a PhD in Core Bluetooth.

And then finally, we wanted to build it on the standard. We wanted you to be able to go and look at the standard and then come and look at Core Bluetooth and go, oh, okay, that's what a central is. Because it says right here in the core spec, that's what a peripheral is. So it ties into the spec itself. And we've been just fanatical in making sure that we're as close as we possibly can to the spec. There is a couple of embellishments. but for the most part, it's spec-based.

So what's unique about CoreBluetooth and what's different between Bluetooth per se is that it's really all about your app. It's nothing to do with the OS. In fact, with the exception of paired devices showing up in the Bluetooth settings, there's nothing in the OS that has anything to do with LE except maybe the little Bluetooth icon that lights up when you have a device connected. And the reason we wanted to do it this way is that we, again, didn't want to shoehorn you guys into specific implementations.

We wanted to give you the power to go and innovate on all of these accessories tied to those use cases that I just showed you, right? So it's really all about you guys, which means that your app is responsible for everything. It's responsible for discovery, connecting to the device, exchanging data.

Craig Dooley, Brian Tucker So we're going to talk about persistent, persisting the device. A lot of people don't realize that they have to store the device because we don't store it. So they need to persist that information, the UID of that particular device. That is all in your app, and most app developers will love that. Some don't. There's other OSes for that.

So what can you do this on? Where does this work? So the first one, of course, was the iPhone 4S. This kind of started it all. This was the first 4.0 capable device that had a Bluetooth 4.0 radio in it. Next came along was the Mac Mini and the Macbook Air.

We just introduced the iPad in the spring of this year and the iPad now has 4.0 capabilities. I mentioned the Macbook Air. One that didn't make it on to this deck because of the timing is all of our Macbook Pros now support Bluetooth 4.0. So the new -- pretty much all the new Macbook Pros that we introduced yesterday -- well, all of them support Bluetooth 4.0. So pretty much any device that your customers are going to use in a portable setting are going to support Bluetooth 4.0, which is pretty cool.

That means in the home, the devices in the home can interact with the Mac. Mac Mini and when you're on the road, the Mac -- the iPhone 4S and the iPad can all interact with your app, right, and with your accessories. But there's another one here that I haven't included because I haven't clicked the button is the iOS simulator.

And we think this is really cool because especially with iOS 6 because now -- let's say you have an idea and it -- I don't know. I don't want to make it a big deal. I don't want to make it a big deal. I don't want to make it a big deal. I don't want to make it a big deal. I don't want to make it a big deal. I don't want to make it a big deal. I don't want to make it a big deal.

I don't want to make it a big deal. I don't want to make up one right now. But you have an idea, and you have an accessory, and you have an app, and you want to make this kind of ecosystem where your app talks to the accessory. What's cool about the simulator is that you can do both the peripheral side and the central side completely in house.

So if you're not a hardware company, fine, but you can still do the peripheral, the interaction with it and just make up the data or tie it to some external stimulus, right, and completely develop your solution all within the iOS simulator. And then when you're ready, then go and deal with your hardware manufacturer, and if you are a hardware manufacturer, now develop the firmware, right, that actually sits inside the single-mode device to do all this. Super, super efficient. And you never had to touch a piece of hardware. So it's really, really great, right? You can debug. You can do everything within the simulator.

Framework. So there's a lot of acronyms up there, but all you have to really focus on for your applications is the top two, your app and Core Bluetooth. We have all of these technologies in our products like GATT and AT and LTCAP and GAP and all these acronyms that everybody loves to throw out. But you don't have to worry about it.

So we're encapsulating this within Core Bluetooth so that you don't have to worry about being an at expert. And that's just me you don't want to be. So that's our framework. So I had showed you this slide before, but I'm going to show you this because I want you to understand kind of the relationship between the peripheral and the central because I'm going to show you the object model.

And if you understand this, I think it will click. So now that you guys have seen that, let's look at our primary objects. So we have CB central manager, Core Bluetooth central manager, which is the object that you use to manage peripherals or devices. And CB peripheral, which is the representation of the device that you either have discovered for advertising or that you are connected to. Now, we have some data objects, CB service, Core Bluetooth service and characteristic.

And unsurprisingly, these are exactly the same names that I just described to you when we talked about Bluetooth LE. Right? And then finally we have a helper object, CB UUID, not to be confused with CFUUIDRef. And then we have a core Bluetooth UUID. I don't know how many times that's happened.

But this is a representation of the Core Bluetooth UUID. And the reason this is there is, again, I go back to the point that every single thing in LE is based on a UUID. So we figured we'd make it easy for you and pass these objects around rather than big, long strings.

But in iOS 6, we added a whole new set of classes. Now, we're going to go into a whole lot of detail on this in the next hour. But I wanted to give you a little sneak peek. So with the development of a peripheral, we now have the opposite side and we have this thing called a peripheral manager and consequently the central and we have these concepts called mutable services and mutable characteristics.

I'll just leave that there but that's how we define, guess what, services and characteristics in your app. And then, of course, attribute or at request. That's a little esoteric. But it will make a lot more sense as we go on. I don't have enough time to get into these in a lot of detail but again, this afternoon. : Real quick, I wanted to mention backgrounding. So a lot of questions around backgrounding. There's two primary ways that you can background your app and talk to accessories.

The first one we call event-based backgrounding. And We feel like event-based background is the most efficient way that you can develop an app on iOS and talk to accessory.

So that's why we created session-based notification or session-based backgrounding. And in session-based backgrounding, pretty much you can do anything you want with the accessory. It's full access to the peripheral. You can scan for peripherals. There are some limits.

You can connect to the peripheral, you can exchange data with the peripheral, pretty much anything that you could do in the foreground, you can do in the background. There are some limits because of power. The only thing that we ask is that you use this concept of discrete start and stop. This concept that I'm going to, for example, my heart rate monitor, I'm going to go for a run, and in that run, my heart rate monitor talks to my app on my phone and they have a conversation.

It's like slow down, speed up, whatever, right? So it has to monitor it in real time. We get that. But if I'm just sitting there programming, I probably don't need to be monitoring my heart rate. Some of you do, but it's not that useful, right? So we really try to encourage this start and stop model within session-based backgrounding.

Okay, so that's a really, really brief overview of CoreBluetooth. Now, we'll get into a lot more detail again this afternoon. I know I keep harping that. But we just couldn't cover this all in one session, so that's why we have two. And Joachim will go into a lot more detail on this. But what I'd like to do now is invite up Craig Dooley, and he's going to give you a demo of the heart rate monitor actually working with the MacBook Air. So, Craig? Morning. Thank you, Brian.

So at this point, you have a pretty good understanding of how Bluetooth Low Energy works, but I want to give you a quick demo and show you what it really takes to put this in your app. So I have one of these Polar heart rate belts. You can just go buy these from Amazon. And I've got a demo application here.

So we can just launch this, look for our device. And now we're connected and in just a second we should be seeing real-time heart rate data. As you can see, I'm very excited to be talking to you about this. So what did we actually do? As Brian said, you can define your own services and characteristics that contain any type of data you want.

But in this case, we're going to talk to a standardized profile. And this is the heart rate profile. So we just have a couple of defines here. We're going to define the service and the two characteristics that we care about. And if you're interested in this, you can go to the Bluetooth developer portal at developer.bluetooth.org.

So now that we know what kind of data we're looking for, let's start our app. So the first thing we're going to do is we're going to instantiate a CB central manager object. And this represents your local device. This is how you're going to perform all the interactions against your local radio.

Things like I want to start observing devices as they come by and I want to connect to them. So we're going to pass in ourself as the delegate. We're going to pass in nil for the queue, which will choose the best queue for us, in this case, the main queue. And now we can get started with our app.

So when we started, we had no idea what devices were around us, no previous interactions with this device. So the first thing we're gonna do is we're gonna call Scan for Peripherals with service. And there could potentially be a lot of things around you. Like Brian said, there could be thermostats, there could be soil moisture sensors.

But in this case, we only care about heart rate monitors. So we're gonna pass in an array. And we're gonna say we only care about heart rate monitors. And then this will tell the system and the radio, start looking for devices that are advertising that service. And when we find one, we'll get this callback.

Central Manager, so just gives you a handle to the Central Manager that you're using, did discover Peripheral with advertising data and RSSI. The Peripheral is your handle to talk to the remote device. The advertising data can contain a couple different things. It contains what services that device supports, a friendly name in case you want to show something in your UI, what power the device is advertising at, and also RSSI, which gives you the signal strength that you saw that device.

So if you want to do something with proximity, this is how you can tell approximately how close your device is based on how much of the signal was lost in transmission. In our case, we don't want to do proximity, so all we're going to do is add this to the list that we showed of devices.

Once we've decided that's the device we want, all we have to do is call CB Central Manager, connect to peripheral. Or connect peripheral. Now, a cool thing about this is this won't time out for you automatically. So if you want to do something like home automation or security, you can actually have your list of devices and just say, I want to connect to this device, and minutes, hours, even days later when someone walks close to you, as soon as the radio sees this device, you'll actually have a connection.

After we connect, you get central manager, did connect peripheral. And at this point, we have the two-way communication with the device. So we want to start interacting with that data. You'll remember that everything is in the structure of services and characteristics. So the first thing we have to do when we connect to the device is discover the services on that.

So we're going to say, I want to be the delegate for this service. And then we're just going to ask, discover all the services on the device. After that goes out over the air, it's going to find all those services, and there could potentially be a lot on the device, things like the device name, device information could have a vendor ID and product ID. It could have the current battery level.

But for this app, it's really simple. All we care about is heart rate. So we're going to iterate over all the services on that peripheral. And if we find a heart rate service, which is the one that we care about, we're going to discover all the characteristics underneath that service.

Again, this will go over the air. And after it's done, you'll get peripheral, did discover characteristics for service, and potentially an error. If you remember from Brian's other slide, heart rate monitor can contain a couple things. All we really care about for this demo is we want the current heart rate measurement and potentially the body sensor location.

So for heart rate, it's not something we really want to pull this data. We don't want to sit there and ask the device, "What is it now? What is it now?" So we're going to say peripheral, set notify to yes on that characteristic, and then whenever the heart rate monitor has new data to send, it'll just deliver that to us. and for body sensor location, I'm not going to be moving around a lot, so I only need to read that once. So in this case, we'll call peripheral read value for characteristic.

And both of those are actually going to call back on the same delegate method. Peripheral did update value for characteristic. So whether it's because you asked for it or whether the device is just giving you new data, whenever there's something updated on that characteristic, this is the callback you'll get. And then we can do whatever we want with it. So the characteristic gives us back a blob of data in NSData. If it's heart rate measurement, we're going to update the current display.

If it's body sensor location, we can do what we want with it. And that's really all we have to do to connect and interact with the device. So this application is actually available as sample code on the developer site, and I can't wait to see all the apps you guys are going to write. Thank you.

Thank you, Craig. And that's available now, so you guys can go download this literally right after this session. Skip your lunch because you want to do this. Trust me. These heart rate belts are available now. In fact, we bought these on Amazon like this weekend. So you can grab these. And it's a great way to actually start developing is to grab a real accessory and start working with that accessory immediately.

One thing I wanted to comment on our best practices, we have a lot of really great stuff in our Bluetooth Guidelines document. Now, this location that I have up there is the Guidelines document that's pretty much available to the world. You guys, because you're here at WWDC and you're Apple developers, have access to the latest release of this, which is our release six, that you'll see on your developer portal for iOS and Mac developers. So definitely go check that out. Another thing you should be reading tonight, along with the course spec, to help you sleep.

But no, there's a lot of really great stuff in there. We talk about advertising intervals. We talk about connection intervals. We talk about all the new stuff we've done with Peripheral Manager, as well as all the stuff around Bluetooth. We have a bunch of people here to help you along the way.

These two guys, Steven Schick and Craig Keithley, they are awesome. And they are here to help you develop your products, both software and hardware. They have expertise pretty much across the board, and these guys really, really care about you and your products. Developer programs, obviously, you can check out our MFI programs. We do have a mailing list.

We also have developer forums now. So we have entries in our developer forums. And there's also a site not related to Apple, but definitely related to LE, and that's developer.bluetooth.org. And if you're curious about all the standard IDs or all the UUIDs, definitely go check them out. Because all of those are there for you as reference. In fact, Craig commented on that in, I think, one of his comments in his code. And that's really, really useful. I keep mentioning this other session.

Here it is, Advanced Core Bluetooth. This is just after lunch at 2:00 PM. You don't want to miss it. Joachim has a ton of data that takes what I said and just adds-- it compounds on this and adds a ton more meat to-- and tips and tricks and things that we've learned working with you over the last year. And I think that's really, really important. And I think it's really important for us to be able to work with you and to be able to work with you in the future.

So with these devices, our portable products, right, our iPhone, our iPads, our MacBooks, You know, it's really about the use cases. It's about the experiences that your customers have using these products in your applications. And it's really amazing now, to me at least, that we've come into this world, this environment, where we can literally start to connect all of these different models. We really can create that Internet of Things. And we can do it in a practical, real way. It's not theoretical.

It's not someday we'll get this protocol, but let us do it. We feel right now with Bluetooth LE and Core Bluetooth that we can actually do this now. And you guys can make just crazy stuff. So fundamentally, connect the world. Connect devices, connect accessories to your apps through our iOS devices, through our Mac devices. And we just absolutely cannot wait to see what you guys come up with. So thank you very, very much for allowing me to talk to you. Enjoy the rest of the week. Have a great week.