WWDC2014 Session 701

Transcript

X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
>> 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."
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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 Bluetooth.org 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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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 Bluetooth.org
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
>> OK. OK.
>> Please.
I'm not his boss so I
still have to say please.
>> 1, 2.
>> 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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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:
developer.apple.com 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 developer.apple.com,
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.