Designing Accessories for iOS and OS X 

Session 701 WWDC 2014

Learn how to create app-enabled accessories. Understand your options for designing accessories that connect via Bluetooth, Wi-Fi or the Lightning connector. Learn how to develop accessories that work with HealthKit and HomeKit.

Good morning, ladies and gentleman.

Thank you for coming today.

My name is Robert Walsh, and I manage the Platform Accessories team at Apple.

And today we’re going to be talking about designing accessories for iOS and OS X.

So, we’ve got a packed session, so let’s dive right in.

We’re going to start by talking about accessory interfaces and the protocols you speak over those interfaces, and then the fun bit, we’ll get on to what’s new in iOS 8 and OS X Yosemite.

And finally, we’ll wrap up with some information on the important programs that you need to know about, such as MFI.

Before we start, though, I’d like to draw your attention to the accessory ecosystem as a whole.

I think if we were to describe the accessory ecosystem in one word, it would be “huge.”

We couldn’t even begin to go through all of the categories of devices which you, you have produced for us.

So, this, this session we’re going to focus on two particular areas, health and fitness accessories, which is the HealthKit framework which you heard about yesterday, and home automation accessories, which is part of the HomeKit framework.

So, first, let’s recap our interfaces.

All of our products support Bluetooth and Wi-Fi, and on iOS devices, you have the option of a wire connection via the Lightning connector.

On OS X, those platforms provide USB and Thunderbolt support.

And both of our platforms also provide support for a 3-and-a-half mm headphone jack.

Let’s start with Bluetooth.

We’ve got some interesting new Bluetooth features this year.

First up, Bluetooth Low Energy.

Now, this isn’t the new interface to our device.

We already support general communication, which are applications via the core Bluetooth framework, and we support the Apple Notification Center service, which allows your accessory to receive notifications from the iOS device.

We also support low-energy audio for producing hearing aids.

And of course we support iBeacon, which provides location services.

This year, we’re adding two new profiles to Bluetooth Low Energy.

These are support for HealthKit accessories and HomeKit accessories, and we’ll go into a lot more detail about those shortly.

I also want to draw your attention to the Apple Notification Center service.

We introduced this in iOS 7, and this year we’re adding some enhancements to the feature.

We are now allowing your accessory to respond to notifications with a positive or a negative response.

So, what does that mean?

Supposing you receive a notification of an incoming phone call.

A positive response might answer the call.

A negative response might decline it.

Another example might be a voicemail notification.

A positive response in that case might call back the originator of the call.

A negative response might dismiss it from the Notification Center.

Now, there’s something I want to point out, which is that we don’t really set in stone what those positive and negative responses actually do, and we, we may change them in future releases for any given notification.

So, it’s important when you’re presenting this to your user as an interface that you present it in the generic manner and not actually tie it to what you expect the behavior might be.

Let’s move on to Bluetooth Classic.

We have an alphabet soup of Bluetooth Classic profiles that we support.

I won’t go through them all, but there’s the list.

But we do have some Apple-specific profiles, which we also support.

If your accessory has a battery in it, you can use the headset battery level indicator to tell us about the charge state of your battery, then we can use that to display on the, on the iOS device, for example.

We also provide Siri Eyes Free.

This is primarily of interest to automotive vendors.

It allows them to allow their drivers to interface with Siri in a safe manner while they’re driving.

Oh, and one other thing I forgot to mention, we also provide iAP1 and iAP2 support over Bluetooth, and that opens up the entire MFI ecosystem of functionality.

And moving on to Wi-Fi.

All of our devices support Wi-Fi up to 802.11ac, dual band operation, and I think the primary consumer, from your perspective of that so far, has been AirPlay and Wireless Accessory Configuration feature.

And this year we’re adding in support for HomeKit accessories over Wi, over Wi-Fi.

Again, we’ll talk about that later.

Let’s move on to wired options.

If you need a wired option, it’s probably because you need to power your accessory or provide power to the device, or you just need the bandwidth, bandwidth that a wired connection can offer.

On iOS devices, we offer the Lightning connector, and this year we have some new functionality to offer you.

We’re offering a Lighting headphone module.

Now, this a module that breaks that analog audio for you, and it connects straight into the Lightning connector on your iOS device.

So, why would you want to do this instead of just using the regular 3-and-a-half mm jack?

Well, for one, it also provides a digital interface to the device so you can offer richer controls to your users, such as integration with iTunes Radio.

If your headphones, for example, support let’s say noise cancellation, you can offer an app on your device that communicates with your headphones to control how that operates.

And there’s one big thing that isn’t listed here, and that’s power.

The Lightning connector is capable of powering your accessory, so you don’t need batteries in your headphones, for example, to power your noise-cancellation functionality.

This year, we’re also offering some new connector modules.

These are targeted at people who are designing form-fitting cases and cables, and they’re a small form factor with those, those products in mind.

You can come and talk to us at the Accessory Labs later and we’ll be happy to go into more detail of these for you.

On our OS X platforms, we support USB 3, all currently shipping Macs now support USB 3, which allows up to 5 Gbps per port, and you can draw up to 900 mA per port for your accessory.

If you design your accessories with USB-IF certification in mind, you’ll be guaranteed that they will work flawlessly with our, with our platforms.

All of our currently shipping Macs also support Thunderbolt 2.

And Thunderbolt is an I/O standard that multiplexes DisplayPort and PCI Express onto a single cable.

You’ll use this if you really want the performance of, of the Thunderbolt.

It gives you 20 Gbps per port, and your accessories can draw up to 10 amps, or, 10 watts of power.

In many cases, this means you won’t actually have to provide a power supply for your accessory, an external power supply.

If you’re interested in producing USB 3 or Thunderbolt 2 accessories, please come and talk to us at the I/O Labs.

There’s one going on right now, but it’ll be going until 11:30, and there’s one later in the week.

And last but not least, all of our products also support the standard 3-and-a-half mm headphone jack.

And we also provide a module for you to incorporate it to your products, which allows you to take advantage of the remote control functionality that we offer over this jack.

So, now the fun bit.

What’s new in iOS 8 and OS X Yosemite this year.

At this stage, I’m going to hand over to my colleague, Terry Worley.

He’s going to talk to you about HealthKit accessories.

[ Applause ]

Thanks, Robert.

Hello, my name is Terry Worley.

I’m one of the engineers on the HealthKit team.

So, first thing’s first.

What is HealthKit?

Well, if you saw in the keynote yesterday, this is a brand-new framework that we are introducing in iOS 8.

It provides a rich set of APIs to save and access health and fitness-related data.

This data can consist of weight, step count, nutritional information, blood pressure, glucose.

In fact, there are over 60 types of data that is supported in HealthKit.

Because security is vital when we’re talking about our health information, of course we’re using class A data protection.

But beyond that, we are providing users with extensive privacy settings so that each of us can control access to our health data.

We’re implementing sophisticated searches as well as statistical queries.

Statistical queries might be something like, “What has been my total daily step count every day this month?

Give me a list of those.”

Or, “Give me a list of my average weekly weight over the past year.”

We’re doing unit conversions – Fahrenheit to Celsius, kilograms to stones to pounds – all of these are built right into the APIs.

HealthKit provides notifications about new data.

So, data can come from a number of sources.

A user may have entered what they had for breakfast into a diet app, or it may come through some tight integration with other OS technologies on your device.

Or, more importantly for us right here right now, it’s a seamless integration with accessories.

So, we’re not going to go any more into HealthKit beyond accessories right now, but HealthKit is at the conference, and we’ll talk shortly about what’s coming up with that.

So, for the next few minutes, let’s talk about what HealthKit means to hardware and software developers with respect to accessories.

Now, if you saw this session last year, Brian Tucker got onstage and he spoke of the explosive proliferation of Bluetooth Low Energy devices in the market, over a billion of them in the marketplace just last year.

And he also noted that Bluetooth Low Energy is especially well suited for health and sports and fitness-related applications.

In fact, if we looked around the room, it’s, it’s likely that we would find a lot of Nike Fuel Bands, Fitbits, Withings, et cetera.

I’m even wearing one.

I’ve been wearing one for quite a while now.

In fact, HealthKit is so powerful that it can transform a software engineer, like me, just by working on it.

Someone who shuns the daylight, who spends years sitting behind the computer, living my life by the light of my displays.

Some of you can probably relate to that.

Now, working on HealthKit, I’m using a standing workstation.

I am riding my bike to work, and I’m even wearing a heart rate chest strap on my bike rides.

That has been particularly challenging, because I’ve been keeping that secret from my family for months now.

They’re always looking for clues, “What are you working on at work?”

Well, now they know.

That is the power of HealthKit.

And accessories are playing a vital role in delivering that data to HealthKit.

HealthKit is now uniquely positioned to be the key component to finally bring together all of these accessories, all of these health and fitness apps, by consolidating the data into one centralized source, and this is going to open up a lot of opportunities for accessory manufacturers as well as app developers by providing this new, rich environment, and a lot of data.

So, we want to build accessories.

What is required?

All right, so has provided official specifications for a number of built-in or, excuse me, a number of Bluetooth Low Energy devices.

So, for HealthKit, we’re going to be supporting these four as built-in, or native.

That’s our heart rate monitor, our glucose sensor, the blood pressure monitor and the health thermometer.

So, built-in.

What does that mean?

Well, once you have paired one of these devices with HealthKit, it takes over and it will control the accessory.

It will connect to it whenever it’s in range.

It will gather data from it.

It’ll save it in HealthKit and then it will notify all clients interested in that kind of data.

So, what this means to hardware manufacturers, if you’re developing one of these accessories, you don’t have to ship an app with it because it will automatically work with HealthKit.

And all the apps out there that want to use one of these, they also benefit because they no longer have to worry about the code to pair the devices.

They don’t need to use Core Bluetooth now to manage the connections, the discovery, collecting the data, parsing the data, etcetera.

And so this will provide a, a great opportunity for hardware and software manufacturers.

So, of these four types, what is required then?

What do you need to do to have a native accessory live in the HealthKit world?

Well, the easy answer is, simply adhere to the specifications.

That’s what we’re doing.

So, if you do that, then we’re just going to live happily forever.

Live happily ever after.

There are, however, some best practices that we would recommend.

First of all, implement the optional fields within the service.

For example, the blood pressure service has an optional heart rate field, measurement field.

If you implement that, HealthKit will also extract that data and save that as a heart rate data point in the database and then notify any clients interested in heart rate.

And similar to that, there are some types of optional measurement fields that maybe don’t correspond specifically to a HealthKit data type.

In this example, we’re talking about heart rate, also has an energy expended field.

This is still valuable to implement because HealthKit will save these other kinds of data as metadata along with the original measurement, in this case, heart rate.

So, you can still access that data.

Implement optional characteristics.

For example, a sensor contact.

If you have a heart rate chest strap and it indicates that there is no sensor contact, then HealthKit will not save that data to the database.

That helps maintain integrity of the data.

So, implement optional characteristics like that.

Implement optional services.

There aren’t a lot of them, but battery services is a good example.

So, if you’re implementing battery service, then HealthKit can look at that and respond accordingly when battery levels are low.

All right.

Now, what if you are developing an accessory that doesn’t fall into one of those four categories?

That is awesome.

Please continue to do so.

All custom accessories are very much welcome in the HealthKit world.

So, what do you need to do?

Go ahead and use the external accessory framework.

Use Core Bluetooth, whether Classic, Low Energy, use Wi-Fi, use USB, whatever technology makes sense for you and your device, do it.

Then in your app that’s controlling that device, simply use the HealthKit APIs to save that data into HealthKit.

It will then be notified, or all clients will be notified about that data as well.

So, we are very hopeful that custom accessory manufacturers will join into the HealthKit party.

It’ll make a much richer environment for everybody.

So, we’ve been talking about these devices getting data in.

So, how do you then know when some heart rate data has been added to your, into HealthKit?

Well, let’s step through a quick example here.

All right, this is HealthKit code.

I think this is the first HealthKit code of the conference.

So the first thing you’ll want is you’ll want a HealthKit Health Store, and in this case I’m just going to define it as a property and initialize what, an instance of it.

As you can see, I am consolidating a bit here for brevity, so don’t expect this to compile like this, and we’ll leave it an exercise to the reader as to where that might actually go in your code.

And I also apologize.

This is the archaic Objective-C language.

And so we are, we’re still going to work through that.

All right.

So, now that we’ve done that, now what’s the interesting part is we’re going to create a HealthKit data object type.

And in this case, we are interested in heart rate.

So, once we’ve created that heart rate object, we’re now going to create an observer query using that heart rate object.

And you see on the line of code there’s also one called predicate.

The predicate provides a lot of filtering options for you.

We don’t really care, we just want to be notified about everything when, and so we’ll just pass nil.

And then we have an updateHandler.

Now, this updateHandler is called whenever the database changes with regard to that data type, you will be notified.

So, it’s inside the handler then that we want to add the code that we’re interested in and this is going to be app-specific.

Maybe you just want to update some UI.

Maybe you want to trigger some other kind of event or do some statistics, whatever.

So, in this case, I’m just saying fetch new samples, and that would go retrieve those samples from the database.

That’s going to be covered in the next HealthKit session, so we won’t go any farther into that.

But now that we’ve set up our observer query, next, the last thing we need to do is take that Health Store object and execute the query.

So, this query can live for the lifetime of your app or until you say stop.

So, anytime heart rate is entered into HealthKit, you will be notified.

So, let’s see some of this in action.

I’d like to invite my colleague, Jorge Morinigo up to the stage with me.

[ Applause ]

Good morning, everybody.

Good morning, Terry.

Jorge. You didn’t get the dress code memo, did you?

Oops. En que vive.

For the record, there was no dress code memo.

It was pretty cool.

Jorge is dressed up in athletic gear because he is wearing a heart rate chest strap.

So, we’re going to go to our iOS device.

On the screen, you can see we have two apps of interest.

One is the “Health” app that was introduced yesterday.

So, let’s launch “Health,” and we will go to the Health Data tab, and we’ll choose vital signs and heart rate.

And we see we have an empty chart.

Go to Show All Data, we’ve got nothing.

So, we need to get some data in here, Jorge.

OK, I’m ready.

All right.

So, let’s go to this, and there’s a heart rate.

And we are now connected.

And I should also point out that in the seed you received with the conference, the pairing is happening here in “Health.”

Future seeds may not be here, so if you don’t find it, then go back to the Settings app under Bluetooth to try that.

And we go our chart and we see we already have new data coming in.

So we go to Show All Data, and there we go.

So, now with that running, let’s launch our demo app that Jorge has provided for us.

Jorge, your heart rate is elevated [laughter].

We, we tried this, we tested this a number of times, and – It was in the 60s.

Oh, it went.

I’m sure it has nothing to do with the fact that you are sitting in front of millions of people right now.

Well, at this point, you know, when we ran through this, it was a, a nice, resting heart rate, and that’s why we had Jorge sitting, because we want to start with a nice, resting heart rate.

I try to relax.

OK, relax.

Relax, Jorge.

Let’s watch it come down.

Don’t be nervous.

So we were thinking what we would have Jorge do is actually do some, some pushups for us to, you know, raise the heart rate, but I’m not sure we want to do that, because, because Jorge’s an engineer also.

We don’t want to go too far.

But let’s try it.

Let’s go for it.

Jorge, drop and give me 10.



I’m not his boss so I still have to say please.

1, 2.


3, 4, 5, 6, 7, 8, 9, 10.

All right.

[ Applause ]

OK. What was important here is we did get the delta we were looking for.

So, Jorge will now relax, and that heart rate will come down quickly, I’m sure.

Yeah, there we go.

It’s coming down.

So, now we’ll go back to our “Health” app, and we look at our data, and we can see all these are in there now, 160.

So, we got a lot of heart rate there.

So, in this example, these were both using those same observer queries, both of them running independently.

Heart rate is being added to HealthKit.

Both are being notified and so they both have access to the data.

And that’s our demo.

Thanks, Jorge.

Thank you.

[ Applause ]

So, that’s, that’s basically it for HealthKit accessories.

This next hour, next session, we have our main HealthKit session.

So, we’d encourage you to go that if you want to hear more about HealthKit.

At the end of the day, we have a health and fitness get together.

This will be a more informal discussion and Q and A if you’re interested in that.

Not on this slide, but we also have HealthKit Labs starting today at 11:30 for a couple of hours, I believe, and then again on Friday.

So, if you want to play with around, with some code, come to the labs and we’ll have a lot of HealthKit engineers on hand, and Jorge and I will also be around to help with HealthKit and or accessories.

So with that, we’ll turn the time over to Kevin McLaughlin to tell us about HomeKit.

Hello, everybody.

I’m Kevin McLaughlin, as Terry said.

I’m here to tell you a little bit more about HomeKit.

So, you’ve heard about this a little bit yesterday, and you’d like to learn a little bit more.

So, HomeKit is a new way for you to bring your exciting new accessories to our users.

The home automation accessory situation right now is not as good as it could be, and HomeKit is a way for us to work together to provide a more consistent user experience for our customers that are getting into home automation.

So, today I’m going to be talking, or this morning I’m going to be talking about the accessory side of things a little bit and this afternoon, we have a session at 4:30 for you to come and learn more about the APIs.

So, let’s get right into the protocol.

So, HomeKit Accessory Protocol, you’ll hear me say it a lot of times, but we do have an acronym that we like to use, and that acronym is HAP.

So, you’ll hear me say HAP, that means HomeKit Accessory Protocol.

So, HomeKit Accessory Protocol is the way for you to connect your accessories to HomeKit.

We support Bluetooth Low Energy and IP transports.

IP means if your accessory is able to get onto the same subnet as an iOS device, then you are able to connect to HomeKit.

Bluetooth LE, of course, is direct point-to-point.

Over those transports, we have done a lot of work to create a very secure connection.

So, we have bidirectional authentication in the protocol, so when an iOS device connects to your accessory, both the iOS device and the accessory can authenticate that the entity on the other end is trusted.

And we have per-session encryption, so every time that we connect, we have an encryption key that we use for that session.

I’ll talk a little more about security later.

So, now we have transports and we have security, but to really make, as Craig said, to bring some rationality to this, we need to start defining a common language for us to use to communicate with all of these home automation accessories.

So, we have common functionality definitions that we use, and this uses a model that I’m sure many of you are familiar with, will look familiar, where we have services and characteristics.

So, services describe a collection of related functionality on an accessory, and characteristics then are those individual pieces of functionality.

To give you an idea of exactly what that means, we have defined here, all right, common services that describe common types of functionality that you’ll find on home automation accessories, and characteristics that would be contained in those services.

There are many more than this defined in our specifications, but even though we would like to imagine, you know, we can define every, everything to make it all a nice common language, we know that you and, and other manufacturers are going to come up with many, many very clever and interesting accessories with functionality that we have not defined.

And so the HomeKit accessory protocol is fully extensible, and you can define any custom service or any custom characteristic that you like, pass that to the iOS device through HAP, and that will be then available to applications to use through HomeKit APIs.

You can mix and match Apple-defined services and custom services, Apple-defined characteristics and custom characteristics, any way that you like.

So, an Apple-defined service can contain Apple-defined characteristics and custom characteristics.

A custom service can contain Apple-defined characteristics and custom characteristics.

So, any way that you like to properly describe your accessory.

And finally, on this part, all of the Apple-defined services and characteristics are recognized natively by Siri, and so when you use these services and characteristics, users can use very natural language to interact with and command and control your accessories through Siri.

Now, let me talk a little bit more about the structure of the protocol.

So, as I mentioned, we have Bluetooth LE and IP, and on top of that we use L2CAP and TCP for the transmission management of data.

On top of that, we use the Attribute Protocol and HTTP to provide packaging of the data as we’re sending it.

And then Generic Attribute Profile GATT and JavaScript object notation JSON on the IP side.

This provides the serial, serialization, the description of the services and characteristics as these messages are being sent back and forth.

And then we have HomeKit Accessory Protocol, where we have defined the remaining structure.

So, what is the terminology, the structure of the data that is being serialized into GATT and JSON and being sent between iOS and accessories?

On top of the protocol, we have HomeKit.

Again, we’ll talk more about this this afternoon, but that is the mechanism that makes your accessories available to applications.

So, while I have this diagram up here for you to look at, I want to also take a moment to point out how our security, or where, I guess, our security is applied.

So, on the Bluetooth LE side, we apply encryption on top of GATT, and that means that the values that we’re sending are encrypted.

On the IP side, we apply encryption on top of TCP.

So, there will be a TCP connection made between the iOS device and your accessory, and we will send encrypted packets over TCP.

Inside those packets is the HomeKit Accessory Protocol, the services and characteristics described in JSON, wrapped in HTTP.

So, I’d like to give you just an example of what that looks like.

So, let’s look at a garage door opener accessory and talk about the services and characteristics that that might have.

So, this is an IP accessory, so its top-level block is an accessory block, and that accessory block will contain all of the services for this accessory.

So, our first service is the Accessory Information Service.

Every accessory must have an Accessory Information Service.

This contains information that is metadata that applies to the whole accessory.

So, in this case, for example, we have a characteristic of serial number which will contain the serial number for this accessory.

We also have a special characteristic called Identify, and this also must be supported by every accessory.

And this characteristic defines that the accessory must, when this characteristic is written to, the accessory must do something that will identify it to a user.

So, for example, a light bulb could flash on and off when it receives an Identify characteristic, right.

Or, a thermostat might blink an LED, or an IP camera might beep.

Whatever it is, is fine.

This can be defined by the accessory manufacturer by the accessory, but it must do something that will help a user identify it.

This is particularly useful in the case where you imagine that a user has, say, installed three light bulbs and they want to set up one of those light bulbs, they want to give it a name, and they want to know which one is which, all right, and they can then request for that accessory to identify itself.

So, moving on now to the next service for this garage door opener.

This is the actual garage door opener motor that opens and closes the garage door.

This is the next service.

So, here we have a characteristic for target state.

So, I would like to open the garage door, or I would like to close the garage door.

Then, we have a characteristic for current state.

Is the garage door currently opened or closed, or maybe it’s opening or closing, or maybe it’s stopped.

Something has happened, and maybe there’s an obstruction, and there’s a characteristic to check if there is an obstruction detected.

So, now we’ve described the garage door opener motor, but many garage door openers, maybe all of them, also have a light.

So, now there’s another service defined on the accessory that represents the light bulb.

Lights are straightforward.

In this case, we have just one characteristic for this light, just on, whether the light is on or off, and also we can write to that characteristic to turn the light on or off.

So, this is just an example.

A real garage door opener accessory I imagine would have quite a few more characteristics.

Also, there could be custom characteristics.

For example, I don’t know, a garage door opener motor might have a speed, how fast you want the garage door to open, so there could be a custom characteristic that says motor speed, and that would be included in service too up there for the garage door opener.

So, let’s talk a little bit more about some particular details on the IP side.

So, the first thing I want to tell you is that when your accessory supports HomeKit Accessory Protocol, you get remote access through HomeKit.

This is provided through iOS device connectivity, does not require any special implementation on your accessory to take advantage of this feature.

We use Bonjour for accessory discovery, so accessories are just required to be Bonjour responders.

If you’ve worked on that before, you’ll be familiar with that.

And then on the IP side, different from Bluetooth LE, which I’ll talk about in just a moment, as I mentioned when I was describing the garage door opener, we have a top-level accessory block.

And that top-level accessory block enables IP accessories to be bridges.

So, you can have, for example, a hub that is a HomeKit accessory and supports HomeKit Accessory Protocol, and you might have behind that hub, connected using some proprietary technology, some light bulbs, all right.

Simple example.

So, in this case, the hub is responsible for translating between the proprietary connection protocol that it uses with its light bulbs and HomeKit Accessory Protocol that we use with iOS.

In this case, the hub will present itself as actually having three accessory blocks.

So, it will have one accessory block that includes an accessory information service that represents the hub itself.

It will have another accessory block with an accessory information service that also has a light bulb service that represents the, one of the light bulbs, and then it would have a third accessory block, also with an accessory information service and also with a light bulb service that represents the other light bulb.

So, this is how we handle bridges as IP accessories.

It’s not restricted to bridges.

Any accessory could use that structure, but it’s particularly necessary for bridges.

And finally, in our protocol on IP side, we use HTTP.

The URL scheme is a restful API, so the URL indicates which services and characteristics and accessories are being addressed with each message.

Now, moving on to talk about Bluetooth LE.

Some details.

Bluetooth LE accessories that support HomeKit Accessory Protocol also get the same remote access capability provided by HomeKit leveraging iOS device connectivity.

We have Apple-defined advertisement data for HomeKit Accessory Protocol for LE accessories.

So, this is in the specifications.

You’ll want to follow that.

So, your Bluetooth LE HomeKit accessory is going to advertise to HomeKit.

It’s not going to advertise to your app.

So, your app will then use HomeKit APIs to access your accessory functionality.

Accessories on LE are not identifiable from their advertisement data.

We use randomly generated service IDs so that your accessory will not reveal what it is if somebody is walking around a neighborhood looking for who has what door locks.

They’ll have to walk up to the door rather than just being able to drive down the street.

And as I mentioned earlier, we use security at the application layer or on top of GATT so that we have a very strong security model that is equivalent on LE side and on IP side.

So, we don’t use Bluetooth LE pairing.

So, let’s talk a little bit more about security.

So, we have end-to-end encryption between iOS and accessories so that it doesn’t matter who’s listening in the middle.

Nobody can intercept, inter, inject or understand the messages that are being sent back and forth between an accessory and iOS device.

The initial setup of the accessory is secured directly between the iOS device and the accessory.

So, we use a setup code that you will have to provide on your accessory.

It can be on packaging, it could be on the accessory, that could be randomly generated if you have an LCD.

It could be on a label or engraved on the accessory.

The user enters that setup code to perform the initial pairing of your accessory to HomeKit.

This ensures that we have a very strong basis for our cryptographic relationship between iOS and the accessory.

Our protocol also has perfect-forward secrecy.

If you are a security or encryption guru you know what this means, but I’ll summarize quickly.

It means that the encryption key that we use for sending messages back and forth cannot be used to decrypt messages from any previous session or any future session.

So, every communication session has a unique encryption key.

To implement all of this, we use standard encryption algorithms because it’s always best to have lots of scrutiny on the encryption that you’re using.

So, we use these algorithms.

There’s much more detail about how these algorithms are used in implementing HomeKit Accessory Protocol in our specifications, and if you do have questions about this, you can bring those questions to our lab on Thursday, the HomeKit Lab, and of course there’s support available through the MFi program for you to get this security right.

Now, wrapping up, so, next steps.

So, first of all and most important, if you’re making accessories, you need to go become familiar with the MFi program if you are not already.

Through the MFi program, you’ll get access to all of our specifications that define everything I’ve talked about here, explain to you how to implement all of the security, the pairing, the protocol and the profiles on your accessory.

You also get access to a great development and certification tool.

It’s an OS X application.

It provides you something to connect your accessory to while you’re doing development.

It implements the security.

It implements the protocol, everything correctly, and it provides you great debug information to help you figure out what’s going on to get your accessory working correctly.

And all of this is available very soon, so please check in there and get started.

And then of course, to learn more about the HomeKit APIs, come to our session this afternoon, that’s at 4:30, and you come to our lab on Thursday, which I believe is at 12:45.

And with that, I’m going to wrap up.

I’m going to hand back to Robert, who’s going to tell you some more about AirPlay.

[ Applause ]

Thank you, Kevin, and thanks also to Terry and Jorge.

That’s some fascinating stuff, and I’m really looking forward to seeing what kind of accessories you guys produce this year with this.

Let’s talk about AirPlay.

As you know, AirPlay is our solution for streaming high-quality digital audio to your accessories.

We provide a reference platform for this.

It’s a source drop that you can use and incorporate into your platforms.

A lot of OEMs are actually taking this and producing modules that you can just drop right into your speaker solutions.

We’ve made some changes to this this year.

We’ve made changes around audio handling.

If your accessory can do this, we’re allowing you to do skew compensation on the accessory side this year.

We’re also changing the way we do buffer underrun handling, and we think both of these are important.

But we should point out that if you’re not comfortable in actually doing the kind of qualitative audio testing you’d need to do in order to take advantage of these, just leave them at the default settings where we do the accessory-side skew compensation or the device-side skew compensation, for example.

This year, we’re also introducing a new reference platform.

If you take our AirPlay source drop, it’ll compile out of the box on, on that BSD running on a Raspberry Pi platform.

You will need to provide the authentication co-processor of course, but it’s, it’ll work just right out of the box.

Both of these will be available with our source drop, which should happen sometime around the iOS 8 release later in the year.

Next up, let’s talk about iAP and the external accessory framework.

So, this year we’ve, well, it’s been two years now since we released iAP2.

We’ve had a lot of feedback from developers, and this year we’ve made some changes to both of these to incorporate your feedback.

So, let’s get right into that.

For iAP2, we’ve made a bunch of media playback enhancements for your accessories to take advantage of.

We’re now allowing iAP2 accessories to get access to the media playback queue.

Now, I should point out that this queue isn’t always available.

For example, if you’re playing back a Genius mix, we may not have the information about what’s coming up next.

Similarly, third-party applications may not have that information.

You don’t know what’s coming up next in, for example, Pandora.

But if you design your accessory with that in mind, you should be able to get it, when the playback queue, when it’s there.

We’ve also added messages for allowing you to play all tracks, something that a lot of people asked.

Just a simple mechanism that says play everything on the device.

And we’re allowing you to sync to a specific time within a track.

This one probably needs a little bit of explaining.

We’re allowing you to get non-localized bundle identifiers for the Now Playing app.

So, up to now, we’ve given you the name of the Now Playing app, but that may have been localized based on what language the device is currently set to.

So, this year we’re allowing you to get the bundle identifier for the app as well.

That way, if you’re tailoring your accessory’s user interface to mirror some, some functionality with the Now Playing app, for example, you can actually identify that Now Playing app without having to identify it in 50 different languages.

And finally, in media playback, we’re allowing those accessories that synchronize with the media library to get progress information on the state of the synchronization.

And you can use this information to display a spinner or a progress bar to your user so that they have some idea of what’s going on and that media library is still coming across to the accessory.

We’ve made some additional enhancements that aren’t media related.

iAP2 accessories can now get the time on the device.

You register for a notification, and when the time changes, we’ll send it to you.

Now, by changes I mean major changes.

We’ll send it to you right off the bat when you register for the notification of course, but we’ll also send it to you when midnight rolls over, daylight savings time kicks in, or the user just manually modifies the time on the device.

For those of you producing accessories that charge the iOS device, we are now providing detailed charge state information in iAP2.

So, for example, if you have a battery case, you may want to decide that you want to charge the battery in the case as opposed to the battery in the device from an external power source.

And you can use this detailed charged state information on the device to determine when you should do that.

For those of you who use our link layer reference platform, we’ve added in a bunch of compile options this year that allow you to really slim down the, the bill size of that.

So, if you’re trying to fit the link layer into a small micro-controller, this should make your life a lot easier.

And finally, for the external accessory proto, framework, we are now allowing multiple apps simultaneously to communicate with your accessory.

Now, we’ll only do this if you tell us that your accessory is capable of handling that, but we highly recommend that your accessories be capable of doing that.

Next, let’s talk about wireless accessory configuration.

We introduced wireless accessory configuration last year as a simple and convenient way for your users to put their Wi-Fi accessories onto their network.

It’s been well received, but we’ve had one persistent request from developers, which is to allow initiation of the wireless accessory configuration process from within their applications.

So, this year we’re allowing this.

This new functionality is exposed through the external accessory framework.

Simply import the framework.

You implement an accessory browser delegate, and you instantiate an accessory browser.

You use the browser to initiate searching for unconfigured Wi-Fi accessories.

I’m not going to call that name out because it’s rather long, but I will say that you can add a predicate to that to narrow down the scope of the accessories that you search, that you’re searching for.

In this example here, we’re only looking for accessories by a company called Amalgamated Audio.

You probably want to do this.

I don’t think your apps want find everything that could potentially be configured.

They only really want to find the ones that, that they know how to handle.

As accessories are found, your delegate will receive callbacks.

You should keep a set of the accessories that you, that you’ve discovered and presented to a, to the user in any manner you see fit.

If you’re representing a single accessory, and you’re a pressure speaker dock, your user can select the accessory, and at that stage, you would kick off a configuration of the accessory using the browser configure accessory message.

By the way, notice that we’re passing in a view controller here.

I’ll get onto that in a minute.

OK, so you’ve just called configure accessory.

We’re now popping our UI into your app using that view controller.

The user configures the accessory at this UI.

At this stage, the configuration is proceeding in the background and then the configuration completes.

Then we drop back to your app.

At this stage, you should continue your normal app flow.

Here we’ve searched for the accessory over Bonjour and we’re showing it in a list and allowing you to do whatever your app allows you to do with that accessory.

So, that’s it.

That’s our new features this year.

We’ve introduced some exciting new functionality around HealthKit and HomeKit.

We’ve enhanced the media playback for IEP accessories and we’ve introduced a new framework for you to use app-driven wireless accessory configuration.

We’re going to wrap up: is your go-to site and the MFi program in particular should be your first port of call if you wanted to start developing an accessory.

Also on, you’ll find a wealth of information about frameworks, case design guidelines, you know, Bluetooth guidelines, information about iBeacon and a lot more.

We’d also love to hear from you.

You can contact our technology evangelists at the addresses given here.

And we also hang out on the developer forums.

So, feel free to use those too.

Let’s just summarize some of the sessions that are coming up later.

Later today, in fact right after this, we have a HealthKit session, and later in the afternoon we have a Core Location and HomeKit sessions.

On Friday, we also have sessions around AirPrint and for Game Controllers.

So, if you’re interested in those areas, please go along and see, check those out.

And that’s it.

Thank you all for coming.

I’m looking forward to seeing you during the week.

Apple, Inc. AAPL
1 Infinite Loop Cupertino CA 95014 US