703.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:00.506 --> 00:00:09.456 A:middle
[ Silence ]

00:00:09.956 --> 00:00:11.376 A:middle
>> Good afternoon.

00:00:11.446 --> 00:00:12.266 A:middle
How is everybody?

00:00:13.686 --> 00:00:14.946 A:middle
Really? That's exciting.

00:00:16.315 --> 00:00:16.646 A:middle
[applause] Good.

00:00:16.986 --> 00:00:21.626 A:middle
Good. Well, welcome to
the afternoon of day 2

00:00:21.626 --> 00:00:23.346 A:middle
of the Worldwide
Developers Conference.

00:00:23.686 --> 00:00:27.406 A:middle
My name is Brian Tucker and
I am ultimately responsible

00:00:27.406 --> 00:00:32.046 A:middle
for Bluetooth here at Apple and
it's a honor and a privilege

00:00:32.116 --> 00:00:35.156 A:middle
to spend a few minutes
to talk to you guys

00:00:35.156 --> 00:00:38.246 A:middle
about what we're doing
specifically in CoreBluetooth,

00:00:38.296 --> 00:00:41.556 A:middle
but in some sense of what we're
doing in Bluetooth in general.

00:00:41.956 --> 00:00:45.876 A:middle
And in a major way where we
think Bluetooth is going.

00:00:46.116 --> 00:00:50.536 A:middle
Right now, Bluetooth is
just absolutely everywhere.

00:00:50.786 --> 00:00:53.926 A:middle
I'm seeing it-- Well, I went

00:00:53.926 --> 00:00:57.406 A:middle
to a Consumer Electronic
Show this winter

00:00:57.406 --> 00:00:59.866 A:middle
and I literally saw
Bluetooth everywhere.

00:00:59.866 --> 00:01:02.506 A:middle
I saw it in trade
show booths walls.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:59.866 --> 00:01:02.506 A:middle
I saw it in trade
show booths walls.

00:01:02.506 --> 00:01:04.465 A:middle
I saw it in people's shirts.

00:01:04.516 --> 00:01:07.886 A:middle
I saw-- I think I saw a couple
of tattoos on people's arms.

00:01:07.886 --> 00:01:10.096 A:middle
I swear. Bluetooth is
literally everywhere.

00:01:10.366 --> 00:01:13.096 A:middle
So it's super, super
exciting times for us

00:01:13.096 --> 00:01:14.776 A:middle
to talk about this stuff.

00:01:14.866 --> 00:01:18.396 A:middle
So speaking of which, what
are we going to cover?

00:01:18.396 --> 00:01:21.116 A:middle
So we're going to be covering
these particular areas.

00:01:21.486 --> 00:01:24.626 A:middle
I'm going to focus a little bit
on BLE and the State of Union

00:01:24.626 --> 00:01:26.716 A:middle
of where BLE is currently.

00:01:27.056 --> 00:01:30.306 A:middle
We'll get into the evolution
of CoreBluetooth kind

00:01:30.306 --> 00:01:32.856 A:middle
of where we started
to where we are today.

00:01:33.606 --> 00:01:35.956 A:middle
We'll talk about
CoreBluetooth in iOS 7.

00:01:35.956 --> 00:01:38.366 A:middle
Jason is going to take
you through that and some

00:01:38.496 --> 00:01:42.466 A:middle
of the cool new features that I
think you guys are going to dig.

00:01:42.756 --> 00:01:45.566 A:middle
Jason has a demo, a
code demo on that.

00:01:45.566 --> 00:01:48.006 A:middle
He'll go through to the code
tying in to some of the things

00:01:48.006 --> 00:01:50.866 A:middle
that he's talking as
it relates to iOS 7.

00:01:51.166 --> 00:01:53.826 A:middle
And then finally, we have
some tips and best practices

00:01:53.826 --> 00:01:57.156 A:middle
that we've learned by listening
to you guys in the forums

00:01:57.396 --> 00:02:00.556 A:middle
as well as all the phone calls
and visits and conversations

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:57.396 --> 00:02:00.556 A:middle
as well as all the phone calls
and visits and conversations

00:02:00.556 --> 00:02:04.616 A:middle
that we've had over the
last year or so on the do's

00:02:04.616 --> 00:02:07.146 A:middle
and don't's around some
of this technology.

00:02:07.146 --> 00:02:11.136 A:middle
So State of the Union,
so where is BLE today?

00:02:12.036 --> 00:02:15.156 A:middle
Well, I think this number
pretty much says it all,

00:02:16.286 --> 00:02:17.756 A:middle
a billion devices.

00:02:18.206 --> 00:02:21.926 A:middle
Right now, we're--
there is estimation

00:02:22.266 --> 00:02:25.616 A:middle
that over a billion Bluetooth--
low energy devices will ship

00:02:25.876 --> 00:02:28.956 A:middle
by the end of this year and
that includes the last couple

00:02:28.956 --> 00:02:29.516 A:middle
of years.

00:02:29.936 --> 00:02:32.356 A:middle
But that's remarkable
considering this technology

00:02:32.356 --> 00:02:35.686 A:middle
really kind of came in to its
own just a couple of years ago.

00:02:36.166 --> 00:02:39.436 A:middle
So it's just crazy to think

00:02:39.866 --> 00:02:42.086 A:middle
that we've reached
this point so quickly.

00:02:42.086 --> 00:02:44.286 A:middle
In fact, if you look
at the projection

00:02:44.626 --> 00:02:47.946 A:middle
over our BLE devices are
going to be in the market just

00:02:47.946 --> 00:02:49.106 A:middle
in the next few years.

00:02:49.106 --> 00:02:50.906 A:middle
It's just up and up and up

00:02:51.166 --> 00:02:52.926 A:middle
and this is conservative
on my opinion.

00:02:53.236 --> 00:02:55.016 A:middle
It's absolutely amazing.

00:02:55.016 --> 00:02:58.496 A:middle
And this kind of ties into those
used cases that I keep talking

00:02:58.496 --> 00:03:01.086 A:middle
to you guys about,
around all the areas,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:58.496 --> 00:03:01.086 A:middle
to you guys about,
around all the areas,

00:03:01.446 --> 00:03:03.316 A:middle
healthcare for example.

00:03:03.316 --> 00:03:06.906 A:middle
I mean, I was in the lab earlier
today and group after group

00:03:06.906 --> 00:03:09.376 A:middle
after group came up and
talked to me about healthcare

00:03:09.596 --> 00:03:11.526 A:middle
and it's not just
one element of it.

00:03:11.736 --> 00:03:13.896 A:middle
It might be a blood
glucose monitor.

00:03:13.896 --> 00:03:14.666 A:middle
It might be something

00:03:14.666 --> 00:03:17.036 A:middle
that literally controls a
limb attached to your leg

00:03:17.036 --> 00:03:19.736 A:middle
that controls the
robotics that's a part--

00:03:19.736 --> 00:03:23.806 A:middle
I mean it's just crazy where
these products are going to go,

00:03:23.806 --> 00:03:25.906 A:middle
sports and fitness, security,

00:03:25.906 --> 00:03:28.286 A:middle
we talked a little bit
about already, toys.

00:03:28.286 --> 00:03:30.976 A:middle
I hope all of you got to see the
demo and the keynote on Monday

00:03:30.976 --> 00:03:36.446 A:middle
which was awesome, and that was
all Bluetooth LE, pay systems,

00:03:36.446 --> 00:03:37.836 A:middle
time services, proximity.

00:03:38.056 --> 00:03:39.866 A:middle
We have some new stuff in
proximity that we're going

00:03:39.866 --> 00:03:42.606 A:middle
to talk about today and it's
going to come up and more

00:03:42.606 --> 00:03:48.636 A:middle
in a Core Location session
later tomorrow I believe is

00:03:48.636 --> 00:03:50.766 A:middle
when the Core Location
session is.

00:03:51.176 --> 00:03:54.046 A:middle
So without further adieu,
I'd like to invite up Renaud

00:03:54.456 --> 00:03:56.816 A:middle
who is going just to
talk about the evolution

00:03:56.816 --> 00:03:59.006 A:middle
of CoreBluetooth
and get us going.

00:03:59.006 --> 00:03:59.626 A:middle
So, Renaud?

00:03:59.626 --> 00:04:01.056 A:middle
[Applause]

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:03:59.626 --> 00:04:01.056 A:middle
[Applause]

00:04:01.056 --> 00:04:02.856 A:middle
>> Thank you, Brian.

00:04:03.866 --> 00:04:07.416 A:middle
So, we introduced
CoreBluetooth in 2011

00:04:07.416 --> 00:04:10.576 A:middle
and we were the first ones to
support Bluetooth Low Energy,

00:04:10.576 --> 00:04:13.436 A:middle
the mass produced
device in the market.

00:04:14.366 --> 00:04:17.166 A:middle
So if you remember in iOS 5
we introduced two classes,

00:04:17.166 --> 00:04:19.826 A:middle
the CBCentralManager and
CBPeripheral that allowed you

00:04:19.826 --> 00:04:23.866 A:middle
to scan for devices, connect
to them and then exchange it

00:04:23.866 --> 00:04:26.826 A:middle
with them, which allowed
you to do a lot of--

00:04:26.826 --> 00:04:28.336 A:middle
which a lot of applications
already.

00:04:29.566 --> 00:04:35.036 A:middle
In iOS 6, we implemented the
other side of the Java rule

00:04:35.036 --> 00:04:37.586 A:middle
of specification which is they
[inaudible] a peripheral rule

00:04:37.586 --> 00:04:38.496 A:middle
and gets over rule.

00:04:38.496 --> 00:04:43.046 A:middle
And for the CBPeripheralManager,
you were able to implement you

00:04:43.046 --> 00:04:45.516 A:middle
on services and Field
CBCentralRequest.

00:04:45.966 --> 00:04:47.586 A:middle
We also introduced
for the first time

00:04:47.586 --> 00:04:51.436 A:middle
or peripheral database
caching mechanism

00:04:51.986 --> 00:04:55.016 A:middle
which drastically improves
performance especially

00:04:55.016 --> 00:04:59.626 A:middle
on discovery as you may
already use that in your app.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:00.656 --> 00:05:03.376 A:middle
Well, iOS 7 is all
about LE, Evolved.

00:05:03.376 --> 00:05:07.966 A:middle
It's about refining OAPIs
based on new feedback

00:05:07.966 --> 00:05:11.556 A:middle
and because we monitor, first
and foremost the mailing list

00:05:11.556 --> 00:05:12.626 A:middle
and the [inaudible] forums.

00:05:12.626 --> 00:05:14.956 A:middle
We also looked at all your
radars that you sent us.

00:05:15.606 --> 00:05:19.046 A:middle
And we are refining OAPIs and
we're also filling the gaps.

00:05:19.046 --> 00:05:21.706 A:middle
We're also putting the last
remaining pieces of the puzzle

00:05:21.986 --> 00:05:24.436 A:middle
to provide user-based
API, so best

00:05:24.436 --> 00:05:26.016 A:middle
and the simplest
API you can use.

00:05:26.466 --> 00:05:30.936 A:middle
So here's what you're going
to talk, a high level agenda.

00:05:30.936 --> 00:05:34.176 A:middle
We simplified Device
Management in iOS 7.

00:05:34.536 --> 00:05:36.526 A:middle
We got more intelligent
peripherals.

00:05:37.546 --> 00:05:40.156 A:middle
We improved performance again.

00:05:40.156 --> 00:05:44.356 A:middle
And pretty drastically
again, we solved the problem

00:05:44.356 --> 00:05:46.906 A:middle
of application persistence
that some of you may have

00:05:47.496 --> 00:05:50.716 A:middle
and we also did some built-in
services right into the OS.

00:05:51.136 --> 00:05:55.296 A:middle
But before I move
to these points,

00:05:55.296 --> 00:05:58.346 A:middle
I want to have a discussion
with you about the simulator.

00:05:59.316 --> 00:06:05.306 A:middle
In 2011, we had a simulator's
report for all coverage of APIs

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:59.316 --> 00:06:05.306 A:middle
In 2011, we had a simulator's
report for all coverage of APIs

00:06:05.306 --> 00:06:07.606 A:middle
because low energy was
an emerging market.

00:06:07.606 --> 00:06:09.936 A:middle
There was almost no
device available.

00:06:10.576 --> 00:06:12.906 A:middle
We were in shipping
iOS devices until late

00:06:12.906 --> 00:06:14.516 A:middle
in the year with iPhone 4S.

00:06:15.096 --> 00:06:18.226 A:middle
And that made development very
difficult for you and for us.

00:06:18.286 --> 00:06:19.776 A:middle
Therefore, we introduced
a simulator.

00:06:19.776 --> 00:06:23.716 A:middle
In 2013, nowadays,
things are very different.

00:06:23.906 --> 00:06:27.256 A:middle
The market is exploding,
like Brian just told you.

00:06:27.946 --> 00:06:30.156 A:middle
There are many, many
LE-compatible devices

00:06:30.156 --> 00:06:33.166 A:middle
on the market including all
our shipping iOS hardware

00:06:33.166 --> 00:06:34.606 A:middle
and most of them are hardware.

00:06:35.096 --> 00:06:36.196 A:middle
And you also have access

00:06:36.196 --> 00:06:39.086 A:middle
to fantastic third-party
development kits running

00:06:39.086 --> 00:06:41.746 A:middle
on less fantastic OSs,
but very fantastic anyway.

00:06:42.456 --> 00:06:46.916 A:middle
And as we move forward and
implement more and more feature

00:06:46.916 --> 00:06:49.386 A:middle
in CoreBluetooth and we're
moving in a breakneck speed.

00:06:49.386 --> 00:06:54.396 A:middle
It gets harder and harder for us
to give the simulator up to par

00:06:54.396 --> 00:06:56.116 A:middle
with what's running
on the hardware.

00:06:56.116 --> 00:06:59.936 A:middle
We cannot continue properly
supporting all the [inaudible]

00:06:59.936 --> 00:07:03.116 A:middle
goals that you guys may be
able to buy from third parties

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:59.936 --> 00:07:03.116 A:middle
goals that you guys may be
able to buy from third parties

00:07:03.276 --> 00:07:04.486 A:middle
that you can plug on your Mac.

00:07:04.796 --> 00:07:08.356 A:middle
And run it exactly as it
should on an iOS device.

00:07:09.336 --> 00:07:11.226 A:middle
And for these reasons
we are now seeing

00:07:11.226 --> 00:07:13.646 A:middle
that we're dropping
simulator support.

00:07:13.836 --> 00:07:16.916 A:middle
So best way to test
CoreBluetooth is really

00:07:16.916 --> 00:07:20.446 A:middle
on the iOS hardware itself
with all the behaviors--

00:07:20.446 --> 00:07:23.056 A:middle
specific behaviors to iOS,

00:07:23.056 --> 00:07:25.636 A:middle
because all hardware
has specificities

00:07:25.636 --> 00:07:27.376 A:middle
that a simulator cannot obtain.

00:07:27.996 --> 00:07:29.396 A:middle
So we're dropping
simulator support.

00:07:30.076 --> 00:07:31.686 A:middle
I'm sorry about that.

00:07:31.686 --> 00:07:32.776 A:middle
Let's move on to the good stuff.

00:07:32.886 --> 00:07:35.906 A:middle
So I'm going to go into the
major changes in the API

00:07:36.066 --> 00:07:37.696 A:middle
that we are doing in iOS 7.

00:07:37.696 --> 00:07:40.786 A:middle
There's more, more-- There's
much more that you can see.

00:07:41.416 --> 00:07:42.466 A:middle
I'm going to put that down.

00:07:43.086 --> 00:07:43.896 A:middle
There's much more
in [inaudible].

00:07:43.896 --> 00:07:46.366 A:middle
But I'm going to talk
about the major ones.

00:07:46.366 --> 00:07:49.506 A:middle
So first of all, like I said,
we simplified device management.

00:07:49.506 --> 00:07:51.486 A:middle
And you probably all
know this property.

00:07:51.486 --> 00:07:54.316 A:middle
You probably all hate this
property which is UUID

00:07:54.386 --> 00:07:56.076 A:middle
of CBPeripherals and CBCentrals.

00:07:56.526 --> 00:08:00.956 A:middle
Another time in 2011, we
didn't have UUID class

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:56.526 --> 00:08:00.956 A:middle
Another time in 2011, we
didn't have UUID class

00:08:00.956 --> 00:08:02.066 A:middle
in the foundation framework.

00:08:02.066 --> 00:08:04.396 A:middle
Therefore, we use a CFUUIDRef.

00:08:04.536 --> 00:08:08.446 A:middle
Since then we now have
the NSUUID and we're going

00:08:08.446 --> 00:08:11.036 A:middle
to deprecate a UUID property
and we have a new one

00:08:11.036 --> 00:08:12.186 A:middle
which is called "IDentifier".

00:08:12.186 --> 00:08:15.426 A:middle
And which is for all intents
and purposes the same value,

00:08:15.686 --> 00:08:18.096 A:middle
but as a convenient NSUUID.

00:08:18.796 --> 00:08:21.636 A:middle
And also these identifiers,
I know because--

00:08:21.636 --> 00:08:24.626 A:middle
are now going to be created
at discovery, because we know

00:08:24.626 --> 00:08:27.386 A:middle
that you had problems
with these being created

00:08:27.386 --> 00:08:28.206 A:middle
at connection time.

00:08:28.206 --> 00:08:29.456 A:middle
So they will always be there.

00:08:29.486 --> 00:08:30.546 A:middle
I guarantee it to be there

00:08:30.976 --> 00:08:32.546 A:middle
and they are much more
convenient to use.

00:08:33.076 --> 00:08:34.765 A:middle
So UUID is deprecated.

00:08:35.576 --> 00:08:40.296 A:middle
And so peripheral retrieval was
also-- was always very wonky.

00:08:40.885 --> 00:08:44.646 A:middle
So UIVs retrievePeripherals
method that you gave an array

00:08:44.646 --> 00:08:49.466 A:middle
of UUID to [inaudible]
peripherals callback comes

00:08:49.466 --> 00:08:49.996 A:middle
to delegate.

00:08:49.996 --> 00:08:53.126 A:middle
Same thing for the
connected peripherals,

00:08:53.126 --> 00:08:56.276 A:middle
we have the same kind of
asynchronous delegate callback.

00:08:57.556 --> 00:08:59.396 A:middle
This was always wonky.

00:08:59.396 --> 00:09:00.196 A:middle
We didn't like it.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:59.396 --> 00:09:00.196 A:middle
We didn't like it.

00:09:00.196 --> 00:09:00.946 A:middle
You didn't like it.

00:09:01.116 --> 00:09:02.026 A:middle
So we're changing that.

00:09:02.606 --> 00:09:05.186 A:middle
In iOS 7, we're introducing
a new method called

00:09:05.186 --> 00:09:07.866 A:middle
retrievePeripherals
WithIdentifiers.

00:09:08.446 --> 00:09:11.536 A:middle
And whereas before UUIDs are
synchronous callback you had

00:09:11.536 --> 00:09:13.006 A:middle
to wait for, for your objects.

00:09:13.646 --> 00:09:15.156 A:middle
Now, you don't have
to do this anymore.

00:09:15.156 --> 00:09:17.446 A:middle
This is asynchronous method,
it returns to you directly

00:09:17.446 --> 00:09:18.826 A:middle
as the objects you
want to work with.

00:09:19.686 --> 00:09:21.246 A:middle
Same thing for the
connected services,

00:09:21.246 --> 00:09:22.536 A:middle
we also have asynchronous method

00:09:22.536 --> 00:09:25.846 A:middle
for the connected
peripherals, sorry.

00:09:25.846 --> 00:09:29.206 A:middle
And you can also pass an array
service you're interested in--

00:09:29.206 --> 00:09:30.336 A:middle
you are interested in.

00:09:31.016 --> 00:09:34.066 A:middle
So that you don't get just an
anonymous list of peripheral

00:09:34.066 --> 00:09:36.306 A:middle
as you get peripherals that
you are only interested in.

00:09:37.026 --> 00:09:38.566 A:middle
And once you use these methods,

00:09:38.566 --> 00:09:40.586 A:middle
you cans continue using
your CBPeripherals

00:09:40.586 --> 00:09:45.796 A:middle
like you use them before by,
for example, connecting to them.

00:09:46.286 --> 00:09:48.856 A:middle
And so we saw that you
guys, these are a lot

00:09:48.856 --> 00:09:51.066 A:middle
of boilerplate code to find

00:09:51.066 --> 00:09:53.386 A:middle
out whenever a CBPeripheral
was being connected

00:09:53.416 --> 00:09:54.646 A:middle
to it any point in time.

00:09:54.646 --> 00:09:56.776 A:middle
So you had your upper
classes just around that,

00:09:56.776 --> 00:09:57.996 A:middle
just to get this property.

00:09:58.496 --> 00:10:00.616 A:middle
And we have the folders
be simple Boolean

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:09:58.496 --> 00:10:00.616 A:middle
And we have the folders
be simple Boolean

00:10:00.616 --> 00:10:02.666 A:middle
that told you whether a
peripheral was connected or not.

00:10:03.416 --> 00:10:05.006 A:middle
We are deprecating that as well

00:10:05.006 --> 00:10:07.056 A:middle
and we're introducing
a tri-state instead

00:10:07.516 --> 00:10:09.646 A:middle
that tells you whenever a
peripheral is connected--

00:10:09.826 --> 00:10:12.876 A:middle
connected to or simply
connected at any point in time.

00:10:13.186 --> 00:10:16.156 A:middle
Simple change is going to-- we
think is going to simplify a lot

00:10:16.156 --> 00:10:20.236 A:middle
of your code, is
going to be great.

00:10:20.376 --> 00:10:24.306 A:middle
We also improve all
service and validation API.

00:10:24.426 --> 00:10:29.156 A:middle
So for those of you that cared
about that, we had this kind

00:10:29.156 --> 00:10:32.966 A:middle
of bazooka callback that nukes
the world service database

00:10:32.966 --> 00:10:35.056 A:middle
on a peripheral or
when database changed.

00:10:35.586 --> 00:10:38.176 A:middle
And that wasn't really good,
because you had to restart,

00:10:38.176 --> 00:10:39.446 A:middle
rediscover all services

00:10:39.446 --> 00:10:41.266 A:middle
and restart all services
from scratch.

00:10:41.936 --> 00:10:45.566 A:middle
Well, we have a more fine grain
callback that gives you exactly

00:10:45.566 --> 00:10:48.506 A:middle
which services when
validated, and all services

00:10:48.506 --> 00:10:50.376 A:middle
that were not been
validated are still valid

00:10:50.376 --> 00:10:53.016 A:middle
and you can continue using them
without restarting anything.

00:10:53.686 --> 00:10:57.596 A:middle
So again you see all these-- all
these APIs are about refining

00:10:57.596 --> 00:11:00.076 A:middle
and fixing of things we--
that are not proper--

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:57.596 --> 00:11:00.076 A:middle
and fixing of things we--
that are not proper--

00:11:00.076 --> 00:11:02.756 A:middle
that were not proper previously.

00:11:03.206 --> 00:11:05.216 A:middle
All right.

00:11:05.456 --> 00:11:08.106 A:middle
Anyway, going to now-- that's
finished for the API changes.

00:11:08.106 --> 00:11:10.326 A:middle
I'm going to invite Jason
to the stage to talk more

00:11:10.326 --> 00:11:11.856 A:middle
about new iOS 7 features.

00:11:11.856 --> 00:11:12.046 A:middle
[Applause]

00:11:12.046 --> 00:11:12.636 A:middle
>> Thanks Renaud.

00:11:13.346 --> 00:11:16.116 A:middle
So next I want to talk about
something that's very near

00:11:16.116 --> 00:11:17.526 A:middle
and dear to our heart
here at Apple.

00:11:17.586 --> 00:11:20.556 A:middle
I think it's super important
and that's performance.

00:11:20.876 --> 00:11:24.696 A:middle
So in iOS 7 we've made a ton
if performance improvements.

00:11:25.166 --> 00:11:27.626 A:middle
And don't worry I'm not going
to bore you with the details

00:11:27.626 --> 00:11:29.486 A:middle
of each and everyone
that we've done.

00:11:29.486 --> 00:11:32.376 A:middle
But I am going to talk about
two main areas of improvement

00:11:32.376 --> 00:11:33.896 A:middle
that we're really excited about

00:11:33.896 --> 00:11:35.476 A:middle
and we think you guys
are going to love.

00:11:35.806 --> 00:11:37.466 A:middle
The first of those is caching.

00:11:38.206 --> 00:11:40.036 A:middle
So as Renauld said earlier,

00:11:40.556 --> 00:11:43.456 A:middle
we first implemented the
database caching in iOS 6.

00:11:43.746 --> 00:11:45.576 A:middle
And what caching
does is it allows us

00:11:45.576 --> 00:11:48.776 A:middle
to remember the attributes that
we find on a remote device.

00:11:49.176 --> 00:11:51.056 A:middle
So the next time one
of your application--

00:11:51.056 --> 00:11:52.486 A:middle
wants one of those
attributes, we don't have

00:11:52.486 --> 00:11:53.846 A:middle
to go backout over the air.

00:11:54.576 --> 00:11:58.226 A:middle
And these lets us really
make things go a lot faster

00:11:58.226 --> 00:11:59.946 A:middle
and save a lot of power,
'cause we're cutting back

00:11:59.946 --> 00:12:01.636 A:middle
on the unnecessary conversation.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:11:59.946 --> 00:12:01.636 A:middle
on the unnecessary conversation.

00:12:02.526 --> 00:12:05.986 A:middle
So in iOS 6, we are currently
caching two attributes,

00:12:06.456 --> 00:12:08.366 A:middle
cache services and
their characteristics.

00:12:08.366 --> 00:12:09.556 A:middle
And this is working really well

00:12:09.556 --> 00:12:12.426 A:middle
because once you do your
initial discovery it--

00:12:12.426 --> 00:12:13.576 A:middle
they're all in the cache

00:12:13.576 --> 00:12:15.336 A:middle
and discovery will fly
the next time around.

00:12:15.906 --> 00:12:19.396 A:middle
In iOS 7, we've taken the
caching that we've done

00:12:19.696 --> 00:12:22.356 A:middle
and we've extended it,
and we've added caching

00:12:22.356 --> 00:12:23.806 A:middle
for characteristic descriptors.

00:12:23.906 --> 00:12:26.506 A:middle
So now, every attribute
that you can discover

00:12:26.506 --> 00:12:30.046 A:middle
in a remote device's database,
services, characteristics

00:12:30.246 --> 00:12:33.396 A:middle
and characteristic descriptors
will be automatically cached

00:12:33.396 --> 00:12:34.716 A:middle
for you by the system.

00:12:35.586 --> 00:12:37.346 A:middle
So we're really excited
about that.

00:12:37.696 --> 00:12:40.696 A:middle
But you might notice there is
one attribute up there that's--

00:12:40.746 --> 00:12:41.766 A:middle
we haven't talked about yet.

00:12:42.106 --> 00:12:43.576 A:middle
That's characteristic values.

00:12:43.576 --> 00:12:45.116 A:middle
And there's a good
reason for it.

00:12:45.686 --> 00:12:48.496 A:middle
So up to this point,
all of the attributes

00:12:48.496 --> 00:12:50.696 A:middle
that we're caching are static.

00:12:50.956 --> 00:12:52.326 A:middle
Their contents never change.

00:12:52.766 --> 00:12:55.066 A:middle
But characteristic
values can be dynamic.

00:12:55.256 --> 00:12:56.646 A:middle
You see what I mean
by that, you--

00:12:56.746 --> 00:12:58.896 A:middle
we can look at the heart rate
measurement characteristic value

00:12:58.896 --> 00:12:59.546 A:middle
as an example.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:00.176 --> 00:13:01.836 A:middle
So right now, if you're to read

00:13:01.956 --> 00:13:04.076 A:middle
that heart rate measurement
characteristic value,

00:13:04.186 --> 00:13:07.076 A:middle
you'd see that it's at
190 beats per minute,

00:13:07.146 --> 00:13:09.216 A:middle
which by no small
coincidence is right

00:13:09.216 --> 00:13:10.896 A:middle
about where my own heart
rate is at the moment.

00:13:11.396 --> 00:13:16.086 A:middle
But later on if you were to read
it perhaps once I got off this

00:13:16.086 --> 00:13:18.826 A:middle
giant stage with this bright
lights in my face, you might see

00:13:18.826 --> 00:13:22.146 A:middle
that it's dropped down
to under 100, good thing.

00:13:22.886 --> 00:13:25.086 A:middle
So how do we cache this?

00:13:25.086 --> 00:13:25.616 A:middle
What do we do?

00:13:25.796 --> 00:13:29.146 A:middle
Well since the system doesn't
know whether a characteristic

00:13:29.146 --> 00:13:30.806 A:middle
value is static or dynamic.

00:13:31.536 --> 00:13:34.236 A:middle
Your application knows,
because you guys are the ones

00:13:34.236 --> 00:13:35.316 A:middle
who were using this service.

00:13:35.956 --> 00:13:39.056 A:middle
So what we are going to do is
when we discover characteristic,

00:13:39.586 --> 00:13:43.086 A:middle
if we've previously read
that characteristic value,

00:13:43.416 --> 00:13:44.936 A:middle
we're going to pre-fill that out

00:13:45.446 --> 00:13:46.916 A:middle
when we send you
the characteristic

00:13:46.916 --> 00:13:48.136 A:middle
up in your discovery call.

00:13:48.816 --> 00:13:51.666 A:middle
So that if you know that you
just discovered a characteristic

00:13:51.666 --> 00:13:54.146 A:middle
that is static, you know it
will never change, you're done.

00:13:54.286 --> 00:13:55.836 A:middle
You don't even have to
issue that we're going

00:13:55.836 --> 00:13:56.916 A:middle
to wait for that response.

00:13:57.146 --> 00:13:58.416 A:middle
There's nothing left
for you to do.

00:13:58.836 --> 00:14:00.366 A:middle
So we're really excited
about this.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:58.836 --> 00:14:00.366 A:middle
So we're really excited
about this.

00:14:00.366 --> 00:14:01.846 A:middle
We think this is--
this can be great

00:14:01.846 --> 00:14:03.116 A:middle
for a lot of your used cases.

00:14:03.476 --> 00:14:05.806 A:middle
And the best part about
this is you don't have

00:14:05.806 --> 00:14:07.056 A:middle
to do anything to get this.

00:14:07.156 --> 00:14:10.046 A:middle
Just like the caching iOS 6,
it's all handled automatically

00:14:10.046 --> 00:14:11.146 A:middle
for you by the system.

00:14:11.706 --> 00:14:15.296 A:middle
The second performance
improvement that I want to talk

00:14:15.296 --> 00:14:18.966 A:middle
about is something that we've
seen a lot of discussion around,

00:14:19.516 --> 00:14:21.246 A:middle
and that's sending data.

00:14:21.956 --> 00:14:24.356 A:middle
So when we are first
taking a look

00:14:24.356 --> 00:14:26.356 A:middle
at the Bluetooth Low Energy
technology, we're trying

00:14:26.356 --> 00:14:28.906 A:middle
to figure out, OK,
what are people going

00:14:28.906 --> 00:14:29.756 A:middle
to want to do with this?

00:14:29.756 --> 00:14:30.706 A:middle
How are they going to use it?

00:14:31.116 --> 00:14:33.306 A:middle
So we're thinking its
Bluetooth Low Energy,

00:14:33.796 --> 00:14:36.066 A:middle
it's a packet-based protocol.

00:14:36.066 --> 00:14:38.996 A:middle
It's good for sending small
amounts of data back and forth,

00:14:39.036 --> 00:14:40.206 A:middle
but it's not really fast.

00:14:40.296 --> 00:14:44.036 A:middle
So people will send things
like your heart rate.

00:14:44.036 --> 00:14:47.056 A:middle
Or you might send
your GPS location.

00:14:47.626 --> 00:14:50.696 A:middle
And of course there are always
the crazy ones out there.

00:14:51.256 --> 00:14:53.536 A:middle
And they're going to-- they
might send something huge

00:14:53.536 --> 00:14:57.166 A:middle
like all of the information
for one of your contacts.

00:14:57.986 --> 00:14:59.726 A:middle
So maybe a little naive of us.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:00.176 --> 00:15:01.916 A:middle
But to be fair, there
were applications

00:15:01.916 --> 00:15:03.186 A:middle
that sent all of those things.

00:15:03.816 --> 00:15:05.256 A:middle
But then we started seeing apps

00:15:05.336 --> 00:15:07.286 A:middle
that we're sending
a little bit more.

00:15:07.936 --> 00:15:09.476 A:middle
Things like photographs

00:15:10.046 --> 00:15:13.106 A:middle
or they'd be thinking the
week's worth of activity data.

00:15:13.886 --> 00:15:16.756 A:middle
And then we learn that some
of you are successfully,

00:15:16.916 --> 00:15:21.216 A:middle
I might add, using CoreBluetooth
to updates to their devices.

00:15:23.106 --> 00:15:27.646 A:middle
So once we kind of got over the
shock, we took a look, you know,

00:15:27.646 --> 00:15:29.776 A:middle
obviously things are
growing by leaps and bounds.

00:15:29.776 --> 00:15:33.956 A:middle
It's not a single heart rate
value anymore it's entire files.

00:15:34.506 --> 00:15:36.426 A:middle
And we crunch some numbers.

00:15:36.426 --> 00:15:37.956 A:middle
And based on this
current rate of growth,

00:15:38.106 --> 00:15:40.046 A:middle
we're pretty confident
that somewhere out there,

00:15:40.176 --> 00:15:42.936 A:middle
there's a government
contractor who's laboring a way

00:15:42.936 --> 00:15:44.736 A:middle
on an application that's going

00:15:44.736 --> 00:15:47.386 A:middle
to transfer the entire digital
collection of the Library

00:15:47.386 --> 00:15:48.976 A:middle
of Congress when you
walk into the building.

00:15:50.566 --> 00:15:52.726 A:middle
Frankly, it's the--
scares the hell out of us.

00:15:52.726 --> 00:15:54.966 A:middle
But since some of you appear

00:15:54.966 --> 00:15:58.456 A:middle
to have confused Buetooth
low energy with 80211N,

00:15:59.556 --> 00:16:03.426 A:middle
we figure that the least we can
do is take a page from Wi-Fi

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:59.556 --> 00:16:03.426 A:middle
we figure that the least we can
do is take a page from Wi-Fi

00:16:03.426 --> 00:16:05.126 A:middle
and try to make things
go a little faster.

00:16:05.166 --> 00:16:09.596 A:middle
So in iOS 7, we worked on
improving our throughput speeds.

00:16:10.336 --> 00:16:12.346 A:middle
How do we do this?

00:16:12.526 --> 00:16:14.086 A:middle
The primary way we've
done this is

00:16:14.086 --> 00:16:16.316 A:middle
by implementing the
MTU exchange request.

00:16:16.716 --> 00:16:17.836 A:middle
And for those of
you who don't know,

00:16:17.986 --> 00:16:20.336 A:middle
MTU stands for Maximum
Transmission Unit.

00:16:20.636 --> 00:16:22.116 A:middle
And that's the largest
amount of data

00:16:22.116 --> 00:16:23.866 A:middle
that we can send
in a single packet.

00:16:24.836 --> 00:16:28.166 A:middle
Now when we increase this, we
can send more data in one go.

00:16:28.166 --> 00:16:29.736 A:middle
And when we're sending
large amounts of data,

00:16:30.036 --> 00:16:31.666 A:middle
it means we can send
it more efficiently.

00:16:32.536 --> 00:16:35.516 A:middle
It might help to kind of
see exactly what this means

00:16:35.516 --> 00:16:36.906 A:middle
when we're talking
about changing MTU.

00:16:36.906 --> 00:16:39.986 A:middle
So I'm asking you to get
creative with me for a moment

00:16:39.986 --> 00:16:41.156 A:middle
and we're going to imagine

00:16:41.156 --> 00:16:44.596 A:middle
that when you're transferring
data via CoreBluetooth,

00:16:44.776 --> 00:16:46.936 A:middle
you're actually sending
it by Rail.

00:16:48.086 --> 00:16:51.156 A:middle
So you have same data to
send, you package it up,

00:16:51.156 --> 00:16:52.576 A:middle
you take it down to
the train station,

00:16:52.976 --> 00:16:54.466 A:middle
throw it out on the
train, the train leaves.

00:16:55.366 --> 00:16:57.426 A:middle
When you have small
MTU, like what we have

00:16:57.426 --> 00:17:00.496 A:middle
for the default you can
put a very small amount

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:57.426 --> 00:17:00.496 A:middle
for the default you can
put a very small amount

00:17:00.496 --> 00:17:01.756 A:middle
of data on each train.

00:17:01.916 --> 00:17:04.896 A:middle
So you end up with
a lot little trains,

00:17:05.175 --> 00:17:09.026 A:middle
and there's a reason why you
don't often see a train engine

00:17:09.026 --> 00:17:10.396 A:middle
pulling a single car behind it,

00:17:10.866 --> 00:17:12.836 A:middle
because it would be
incredibly inefficient.

00:17:13.445 --> 00:17:15.945 A:middle
And the same holds through
for our Bluetooth Low Energy.

00:17:16.415 --> 00:17:20.156 A:middle
So when we increase our
MTU, like I said before,

00:17:20.606 --> 00:17:24.276 A:middle
we increase the amount of data
that we can send at once or put

00:17:24.276 --> 00:17:25.435 A:middle
on a train if you will.

00:17:25.586 --> 00:17:29.686 A:middle
So we end up with that same
train engine pulling a lot more

00:17:29.686 --> 00:17:30.526 A:middle
data behind it.

00:17:31.056 --> 00:17:34.306 A:middle
So by doing this we've cut
down on the overhead a ton

00:17:34.386 --> 00:17:36.856 A:middle
and that allows us to
send more data in the

00:17:36.856 --> 00:17:39.246 A:middle
in the same amount of time.

00:17:39.436 --> 00:17:42.806 A:middle
So now in iOS 7 when you make
a connection from your app

00:17:43.136 --> 00:17:45.616 A:middle
to remote peripheral, one of the
first things that we're going

00:17:45.616 --> 00:17:47.956 A:middle
to do once that connection
goes through is try

00:17:47.956 --> 00:17:50.666 A:middle
to negotiate a larger
MTU with that device.

00:17:51.376 --> 00:17:54.066 A:middle
And we did some internal testing
while you're working on this

00:17:54.176 --> 00:17:56.686 A:middle
to try to characterize
the amount

00:17:56.686 --> 00:17:58.306 A:middle
of speed improvement
that we have seen.

00:17:58.776 --> 00:18:02.256 A:middle
So we wrote a test app
that streamed large amounts

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:58.776 --> 00:18:02.256 A:middle
So we wrote a test app
that streamed large amounts

00:18:02.256 --> 00:18:05.316 A:middle
of data via notifications,
which is a used case

00:18:05.316 --> 00:18:06.716 A:middle
that we've seen a
lot of you doing.

00:18:07.176 --> 00:18:09.906 A:middle
And we saw up to a
20 percent increase

00:18:09.906 --> 00:18:10.956 A:middle
in throughput speeds there.

00:18:11.866 --> 00:18:13.766 A:middle
And you don't-- this comes
with the standard disclaimer,

00:18:14.576 --> 00:18:16.246 A:middle
this is very used
case dependent.

00:18:16.346 --> 00:18:18.006 A:middle
It's going to depend on a lot

00:18:18.006 --> 00:18:20.456 A:middle
of things you may see
less, you may see more.

00:18:21.636 --> 00:18:23.936 A:middle
Things that could affect us
are your connection interval,

00:18:23.936 --> 00:18:27.586 A:middle
the number of connection events,
what you had for breakfast

00:18:27.586 --> 00:18:30.506 A:middle
that morning, the face of the
moon, you know, you name it.

00:18:30.506 --> 00:18:33.176 A:middle
There's a lot that comes in
the play here, but all of this

00:18:33.176 --> 00:18:37.646 A:middle
to say that it can be a very
nontrivial speed boost for those

00:18:37.646 --> 00:18:39.256 A:middle
of you who are sending
large amounts of data.

00:18:39.356 --> 00:18:41.846 A:middle
And even if you're not you
should still see a bump in kind

00:18:41.846 --> 00:18:43.856 A:middle
of your standard activities
like your discovery,

00:18:43.856 --> 00:18:45.026 A:middle
your reads and your writes.

00:18:45.256 --> 00:18:47.966 A:middle
And again, let's save the
best part of this for last,

00:18:47.966 --> 00:18:49.926 A:middle
because you get this all
for free, you don't have

00:18:49.926 --> 00:18:51.806 A:middle
to make any changes
to your application

00:18:51.806 --> 00:18:54.746 A:middle
to start taking advantage
of this.

00:18:56.146 --> 00:18:58.316 A:middle
So we spend a lot of
time talking about how

00:18:58.316 --> 00:19:00.336 A:middle
to make things faster,
faster, faster, faster.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:58.316 --> 00:19:00.336 A:middle
to make things faster,
faster, faster, faster.

00:19:00.336 --> 00:19:03.006 A:middle
But for all of you who are
familiar with the story

00:19:03.006 --> 00:19:04.056 A:middle
of the Tortoise and the Hare,

00:19:04.576 --> 00:19:07.396 A:middle
you know that it's not
always the fastest one

00:19:07.396 --> 00:19:08.536 A:middle
that wins the race.

00:19:09.156 --> 00:19:12.836 A:middle
Sometimes it's Raphael the
running Teenage Mutant Ninja

00:19:12.836 --> 00:19:13.306 A:middle
Turtle here.

00:19:14.186 --> 00:19:16.826 A:middle
So for all of your Tortoises
out there, we're going to talk

00:19:16.826 --> 00:19:18.756 A:middle
about how to give you
more staying power.

00:19:20.026 --> 00:19:22.766 A:middle
But first let's take a
look at the current state

00:19:22.766 --> 00:19:24.296 A:middle
of multitasking with
CoreBluetooth.

00:19:25.056 --> 00:19:30.396 A:middle
So today, the user launches
their apps, they work well,

00:19:30.396 --> 00:19:31.576 A:middle
they do everything
they're supposed to,

00:19:31.576 --> 00:19:33.006 A:middle
they look great while doing it,

00:19:33.486 --> 00:19:35.896 A:middle
but at some point despite
your valiant effort

00:19:36.486 --> 00:19:38.756 A:middle
that user is going to want
to do somethings else.

00:19:39.236 --> 00:19:40.116 A:middle
Depressing, I know.

00:19:40.326 --> 00:19:41.716 A:middle
They're going to
background your application.

00:19:42.456 --> 00:19:44.356 A:middle
But that's OK, because
that's why we came

00:19:44.356 --> 00:19:46.226 A:middle
up with these two great
backgrounding modes.

00:19:46.526 --> 00:19:49.646 A:middle
And your peripheral managers can
continue to host their services

00:19:49.646 --> 00:19:51.956 A:middle
in the database and field
request from its remote central.

00:19:52.466 --> 00:19:53.556 A:middle
And this work great.

00:19:53.556 --> 00:19:55.076 A:middle
They allow your application
to continue

00:19:55.076 --> 00:19:57.396 A:middle
to use CoreBluetooth even when
it's not on the foreground.

00:19:58.136 --> 00:20:00.806 A:middle
But as many of you may be
aware, there's a problem.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:58.136 --> 00:20:00.806 A:middle
But as many of you may be
aware, there's a problem.

00:20:01.656 --> 00:20:04.066 A:middle
Because while your application
is running in the background,

00:20:04.066 --> 00:20:07.416 A:middle
the system may terminate it if
it needs to free up more memory

00:20:07.416 --> 00:20:08.616 A:middle
for the foreground application.

00:20:09.256 --> 00:20:11.846 A:middle
So it doesn't take a
computer engineer to see

00:20:11.846 --> 00:20:15.146 A:middle
that there might be a problem
here, because a lot of things

00:20:15.146 --> 00:20:15.676 A:middle
that you guys do

00:20:15.676 --> 00:20:18.946 A:middle
with CoreBluetooth
are really long-term,

00:20:19.456 --> 00:20:21.126 A:middle
some of these used
cases can take hours,

00:20:21.126 --> 00:20:22.136 A:middle
they can even take days.

00:20:22.136 --> 00:20:26.206 A:middle
If you imagine an application,
a home security application

00:20:26.206 --> 00:20:28.846 A:middle
that wants to reconnect to your
Smart Lock when you get home

00:20:28.846 --> 00:20:30.886 A:middle
in the evening, well,
a lot of times

00:20:30.886 --> 00:20:33.016 A:middle
if you've been using you phone
heavily throughout the day,

00:20:33.136 --> 00:20:34.936 A:middle
that application
might not be running

00:20:34.936 --> 00:20:36.106 A:middle
by the time you get back.

00:20:36.606 --> 00:20:39.886 A:middle
So the question is,
"Can we allow the system

00:20:40.276 --> 00:20:45.246 A:middle
to reclaim the memory that
it needs while allowing your

00:20:45.246 --> 00:20:48.666 A:middle
application to continue
to use CoreBluetooth?"

00:20:49.796 --> 00:20:51.376 A:middle
And the answer is no.

00:20:51.786 --> 00:20:54.326 A:middle
So I'd like to thank you all
for coming to our session today

00:20:54.326 --> 00:20:55.596 A:middle
and we'll see you
down at the lab.

00:20:55.876 --> 00:20:57.816 A:middle
No, I'm just kidding, of
course, the answer is yes

00:20:57.816 --> 00:20:58.966 A:middle
or we wouldn't be
here right now.

00:20:58.966 --> 00:21:01.196 A:middle
And not only is it
yes, but we've come

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:58.966 --> 00:21:01.196 A:middle
And not only is it
yes, but we've come

00:21:01.196 --> 00:21:02.346 A:middle
up with a really simple way

00:21:02.406 --> 00:21:03.906 A:middle
that we think you guys
are going to love.

00:21:04.916 --> 00:21:05.806 A:middle
So what are we doing?

00:21:06.576 --> 00:21:10.156 A:middle
Well, the systems going to watch
the state of your application.

00:21:10.156 --> 00:21:11.226 A:middle
It knows when it's running.

00:21:11.286 --> 00:21:12.716 A:middle
It knows when it's
in the background.

00:21:13.146 --> 00:21:14.896 A:middle
And it knows when
it gets terminated.

00:21:15.196 --> 00:21:17.746 A:middle
So when that happens,
when it's gets terminated,

00:21:17.746 --> 00:21:19.056 A:middle
we're going to look at why.

00:21:19.546 --> 00:21:22.426 A:middle
And if it's because the system
needed free up more memory

00:21:22.426 --> 00:21:26.476 A:middle
for the foreground app, and your
application was performing some

00:21:26.476 --> 00:21:29.086 A:middle
long-term action with
CoreBluetooth at the time,

00:21:29.796 --> 00:21:32.676 A:middle
then we're going to step in
on your application's behalf

00:21:32.856 --> 00:21:35.256 A:middle
and take over and we'll
continue to do everything

00:21:35.256 --> 00:21:37.066 A:middle
that it was doing when
it was in the background.

00:21:37.866 --> 00:21:40.536 A:middle
At some point later, when you
need your application again,

00:21:40.876 --> 00:21:42.526 A:middle
it will bring you
back and we're going

00:21:42.526 --> 00:21:44.726 A:middle
to give you back everything, we
bring you right back up to speed

00:21:44.726 --> 00:21:46.046 A:middle
where you were before
you went away.

00:21:47.076 --> 00:21:52.576 A:middle
So we're calling this-- So
we're calling this feature State

00:21:52.576 --> 00:21:53.996 A:middle
Preservations and restoration.

00:21:54.176 --> 00:21:55.536 A:middle
Those of you might be familiar

00:21:55.536 --> 00:21:57.226 A:middle
with the UIKit feature
the same name.

00:21:57.566 --> 00:21:59.256 A:middle
It's pretty similar
conceptually.

00:21:59.776 --> 00:22:03.616 A:middle
So this is an optional feature,
for those of you who don't run

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:59.776 --> 00:22:03.616 A:middle
So this is an optional feature,
for those of you who don't run

00:22:03.616 --> 00:22:05.786 A:middle
into the background or
who aren't interested

00:22:05.786 --> 00:22:07.686 A:middle
in performing long-term
actions in the background,

00:22:08.006 --> 00:22:09.116 A:middle
there's nothing for
you to do here.

00:22:09.456 --> 00:22:12.586 A:middle
If you do care, you should
know that it's fully supported

00:22:12.586 --> 00:22:15.276 A:middle
by both of our manager
classes, CBCentralManager

00:22:15.276 --> 00:22:16.446 A:middle
and CBPeripheralManager.

00:22:17.006 --> 00:22:20.216 A:middle
And there's not much work that
you need to do to adapt this.

00:22:20.216 --> 00:22:20.996 A:middle
It's pretty simple.

00:22:21.286 --> 00:22:23.806 A:middle
You're going to have to create
a unique restore identifier

00:22:23.806 --> 00:22:25.676 A:middle
when you instantiate
your manager objects.

00:22:25.776 --> 00:22:26.796 A:middle
And you're going to have

00:22:26.826 --> 00:22:29.206 A:middle
to implement a single
new delegate method.

00:22:29.616 --> 00:22:31.286 A:middle
That's it.

00:22:32.056 --> 00:22:34.656 A:middle
So how does this work from
the system perspective?

00:22:34.876 --> 00:22:38.076 A:middle
Well, when your application
is terminated,

00:22:38.076 --> 00:22:40.536 A:middle
right before it goes away,
we're going to take a snap shot

00:22:40.536 --> 00:22:41.606 A:middle
of everything it was doing.

00:22:41.886 --> 00:22:44.686 A:middle
Assuming it was performing
some action with CoreBluetooth.

00:22:45.376 --> 00:22:49.056 A:middle
For things like-- central
manager things this is what you

00:22:49.056 --> 00:22:53.116 A:middle
are discovering, the devices
that you try to connect to

00:22:53.116 --> 00:22:56.886 A:middle
or you had already connected to,
and all of the characteristics

00:22:56.886 --> 00:22:58.786 A:middle
that you were subscribed
to on these devices.

00:22:59.686 --> 00:23:02.316 A:middle
And the peripheral manager side
may keep track of everything

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:59.686 --> 00:23:02.316 A:middle
And the peripheral manager side
may keep track of everything

00:23:02.316 --> 00:23:04.966 A:middle
as well, what you're
advertising, all the services

00:23:04.966 --> 00:23:07.786 A:middle
that you'd publish in the
database, and all the centrals

00:23:07.786 --> 00:23:09.566 A:middle
that were subscribed to
your characteristics.

00:23:10.066 --> 00:23:11.656 A:middle
So once we take the snapshot,

00:23:11.656 --> 00:23:13.436 A:middle
your application is
still terminated,

00:23:13.436 --> 00:23:14.466 A:middle
it's no longer running.

00:23:14.466 --> 00:23:15.856 A:middle
But like I said,
we've stepped in

00:23:15.856 --> 00:23:17.656 A:middle
and we're doing everything
on its behalf.

00:23:18.276 --> 00:23:22.446 A:middle
And we said that at some point,
something is going to happen

00:23:22.446 --> 00:23:24.276 A:middle
and we said we'd bring you back.

00:23:24.986 --> 00:23:29.436 A:middle
So any event that the system
either can't handle without you

00:23:29.436 --> 00:23:32.216 A:middle
or that you need to know
about will trigger us

00:23:32.216 --> 00:23:33.556 A:middle
to re-launch your application.

00:23:33.656 --> 00:23:36.486 A:middle
And these are things like
that peripheral you're trying

00:23:36.486 --> 00:23:39.576 A:middle
to connect to finally
completed or someone subscribed

00:23:39.576 --> 00:23:42.486 A:middle
to a characteristic that you're
hosting, or your got an update

00:23:42.846 --> 00:23:45.056 A:middle
to a characteristic that
your were subscribed on.

00:23:45.056 --> 00:23:48.256 A:middle
And at that point we'll
re-launch you back

00:23:48.256 --> 00:23:49.496 A:middle
into the background
where you were.

00:23:50.016 --> 00:23:52.296 A:middle
And allow you to run for
a short period of time.

00:23:52.836 --> 00:23:56.616 A:middle
The application is then going to
reinstantiate all the managers

00:23:56.616 --> 00:23:58.096 A:middle
that I was using
before it went away.

00:23:58.936 --> 00:24:00.636 A:middle
It's going to get that
one delegate callback

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:58.936 --> 00:24:00.636 A:middle
It's going to get that
one delegate callback

00:24:00.636 --> 00:24:02.056 A:middle
where we give you
back all the state

00:24:02.056 --> 00:24:03.306 A:middle
that we're keeping
track of for you.

00:24:03.476 --> 00:24:05.626 A:middle
And then it's kind
of business as usual.

00:24:05.666 --> 00:24:08.796 A:middle
You'll see that power on event
in your didUpdateState callback.

00:24:09.236 --> 00:24:12.626 A:middle
And you're going to get whatever
event triggered us to re-launch

00:24:12.626 --> 00:24:14.406 A:middle
and you'll get that
delegate callback as normal.

00:24:15.426 --> 00:24:17.596 A:middle
So I know it might
seem like there a lot

00:24:17.596 --> 00:24:19.886 A:middle
of moving pieces here,
but I said it was simple

00:24:19.946 --> 00:24:21.646 A:middle
and I'd never lead you astray.

00:24:22.116 --> 00:24:24.376 A:middle
So I'm going to show
you how simple it is

00:24:24.376 --> 00:24:27.276 A:middle
by taking an existing
background capable application

00:24:27.276 --> 00:24:29.966 A:middle
and adding support for state
preservation and restoration.

00:24:30.516 --> 00:24:38.596 A:middle
[ Pause ]

00:24:39.096 --> 00:24:41.536 A:middle
All right, so here is our app

00:24:42.226 --> 00:24:45.506 A:middle
and it's a very simple heart
rate monitor application,

00:24:45.506 --> 00:24:48.086 A:middle
it looks for all the
heart rate monitor devices

00:24:48.186 --> 00:24:49.236 A:middle
that are near you.

00:24:49.296 --> 00:24:51.946 A:middle
It connects to them and
it finds and subscribes

00:24:51.946 --> 00:24:54.316 A:middle
to the heart rate-- at heart
rate measurement characteristics

00:24:54.316 --> 00:24:55.256 A:middle
that we looked at earlier.

00:24:56.666 --> 00:24:58.066 A:middle
It's been pretty
stripped down just

00:24:58.066 --> 00:24:59.746 A:middle
for illustrative
purposes for this demo.

00:24:59.746 --> 00:25:02.586 A:middle
But it should look pretty
familiar for any of you

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:59.746 --> 00:25:02.586 A:middle
But it should look pretty
familiar for any of you

00:25:02.586 --> 00:25:04.446 A:middle
who have worked with
the CBCentralManager

00:25:04.446 --> 00:25:06.186 A:middle
and CBPeripheral classes before.

00:25:06.836 --> 00:25:09.376 A:middle
So before we get started, I'm
just going to take you in kind

00:25:09.376 --> 00:25:10.956 A:middle
of a quick tour through
the code here

00:25:10.956 --> 00:25:13.146 A:middle
so you can see what
we're working

00:25:13.146 --> 00:25:14.566 A:middle
with before we start
making changes.

00:25:15.716 --> 00:25:17.276 A:middle
So this is a single
view controller.

00:25:17.396 --> 00:25:18.856 A:middle
Like I said very
simple application.

00:25:19.136 --> 00:25:21.696 A:middle
Down here in viewDidLoad
where the magic starts,

00:25:21.946 --> 00:25:24.636 A:middle
you can see that we instantiate
out central manager--

00:25:24.696 --> 00:25:25.976 A:middle
single central manager object.

00:25:26.396 --> 00:25:28.586 A:middle
And this object is going to be

00:25:28.586 --> 00:25:31.026 A:middle
around for the lifetime
of our application.

00:25:31.976 --> 00:25:35.436 A:middle
So as you all know after we
instantiate our manager, we're--

00:25:35.436 --> 00:25:36.206 A:middle
the first thing that we're going

00:25:36.206 --> 00:25:38.026 A:middle
to get is a callback
on didUpdateState.

00:25:38.456 --> 00:25:40.016 A:middle
So in this situation when we see

00:25:40.016 --> 00:25:43.066 A:middle
that the state has been powered
on, we simply begin scanning

00:25:43.066 --> 00:25:45.936 A:middle
for devices that are advertising
the heart rate service.

00:25:47.026 --> 00:25:49.186 A:middle
At this point when
we find the device,

00:25:49.186 --> 00:25:51.576 A:middle
we're going to get a callback
to didDiscoverPeripheral.

00:25:51.656 --> 00:25:53.796 A:middle
And there are a couple of things
that I wanted point out in here.

00:25:54.416 --> 00:25:57.546 A:middle
So the first is that you can
see here, we have a list--

00:25:57.546 --> 00:25:59.776 A:middle
we keep a list of heart
rate monitor devices around.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:00.136 --> 00:26:03.986 A:middle
So when you find a device and
you want to use that device,

00:26:04.256 --> 00:26:05.546 A:middle
you need to keep
a reference to it.

00:26:05.966 --> 00:26:09.276 A:middle
So the system knows, "Hey,
this application is trying

00:26:09.276 --> 00:26:10.936 A:middle
to use this device, we
better keep it around.

00:26:11.456 --> 00:26:15.496 A:middle
So we looked to see if we
have this OS in our list;

00:26:15.496 --> 00:26:16.756 A:middle
and if not, we put it in there.

00:26:17.236 --> 00:26:19.226 A:middle
And at that point we call
connect.net [phonetic].

00:26:19.746 --> 00:26:22.306 A:middle
Hopefully, later on that
connection will complete

00:26:22.306 --> 00:26:24.136 A:middle
and we'll get our
didConnectPeripheral callback.

00:26:24.136 --> 00:26:28.946 A:middle
And at this point we simply set
the delegate and then we move

00:26:28.946 --> 00:26:31.986 A:middle
on to kind of the
service interaction part

00:26:31.986 --> 00:26:33.396 A:middle
of our phase of our application.

00:26:33.726 --> 00:26:36.156 A:middle
The first thing we do is
we simply discover services

00:26:36.156 --> 00:26:38.296 A:middle
and we're only interested
that heart rate service,

00:26:38.666 --> 00:26:39.486 A:middle
pretty straightforward.

00:26:40.386 --> 00:26:42.156 A:middle
Later on when the
command completes,

00:26:42.156 --> 00:26:44.456 A:middle
we'll get our
didDiscoverServices callback.

00:26:44.456 --> 00:26:45.646 A:middle
We're going to look
and see, hey,

00:26:45.856 --> 00:26:47.266 A:middle
were we able to find
the service?

00:26:47.516 --> 00:26:49.266 A:middle
And if so, the next
step we're going to look

00:26:49.266 --> 00:26:50.816 A:middle
for that heart rate
measurement characteristic.

00:26:51.926 --> 00:26:54.196 A:middle
Once that completes, again,
we're going to check to see,

00:26:54.196 --> 00:26:56.806 A:middle
were we able to find it,
and we're simply going

00:26:56.806 --> 00:26:59.796 A:middle
to call set notify value
to subscribe updates on it.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:01.096 --> 00:27:03.526 A:middle
Later on when that
value changes,

00:27:03.786 --> 00:27:06.806 A:middle
the peripheral will send
us the new updated value,

00:27:06.806 --> 00:27:09.126 A:middle
we'll get a didUpdateValue
for characteristic callback.

00:27:09.126 --> 00:27:10.736 A:middle
And since this is
such a simple app,

00:27:10.736 --> 00:27:12.116 A:middle
we're not really doing
anything here other

00:27:12.116 --> 00:27:13.376 A:middle
than logging that information.

00:27:14.176 --> 00:27:17.766 A:middle
OK, so I said this is a
background capable app,

00:27:17.766 --> 00:27:19.766 A:middle
of course it wants to do all
of this in the background.

00:27:20.016 --> 00:27:22.766 A:middle
So we're going to go to
the info.plist here and see

00:27:22.836 --> 00:27:27.016 A:middle
that it is in fact specified
the correct required background

00:27:27.016 --> 00:27:29.276 A:middle
mode, app communicates
using CoreBluetooth,

00:27:29.276 --> 00:27:31.366 A:middle
which as you all know
is the appropriate one.

00:27:31.366 --> 00:27:33.606 A:middle
We're going to be using a
CBCentralManager and you want

00:27:33.606 --> 00:27:36.036 A:middle
to continue using peripherals
while in the background.

00:27:38.476 --> 00:27:40.166 A:middle
So one thing I want to note,

00:27:40.646 --> 00:27:44.676 A:middle
you notice that even though this
application is geared toward

00:27:44.726 --> 00:27:46.646 A:middle
CBCentralManager, everything
that we're going to talk

00:27:46.646 --> 00:27:47.856 A:middle
about here for this preservation

00:27:47.856 --> 00:27:50.046 A:middle
and restoration feature
applies equally

00:27:50.046 --> 00:27:51.636 A:middle
to peripheral manages as well.

00:27:52.576 --> 00:27:54.936 A:middle
So the first thing
that it said before was

00:27:54.936 --> 00:27:57.306 A:middle
that this is an optional
feature, so we need the opt-in.

00:27:57.306 --> 00:27:59.646 A:middle
And we're going to go back
down to this viewDidLoad here

00:27:59.906 --> 00:28:02.516 A:middle
where we instantiate our
central manger object.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:59.906 --> 00:28:02.516 A:middle
where we instantiate our
central manger object.

00:28:02.826 --> 00:28:06.526 A:middle
And we're going to move
it to a new init method.

00:28:06.966 --> 00:28:08.656 A:middle
It looks pretty much
the same as the old one,

00:28:08.656 --> 00:28:10.846 A:middle
but now we've got this
options dictionary on the end

00:28:11.436 --> 00:28:14.396 A:middle
and we need to provide a
single new option for this

00:28:14.616 --> 00:28:16.416 A:middle
and that's our restore
identifier.

00:28:17.356 --> 00:28:20.566 A:middle
So by providing this
restore identifier key,

00:28:20.566 --> 00:28:21.586 A:middle
we're doing two things.

00:28:22.386 --> 00:28:26.416 A:middle
One, we are telling the
system and the application,

00:28:26.856 --> 00:28:29.166 A:middle
we're giving them a
way to uniquely refer

00:28:29.166 --> 00:28:30.726 A:middle
to this specific manager.

00:28:31.316 --> 00:28:33.046 A:middle
The second thing that we're
doing is telling the system,

00:28:33.046 --> 00:28:34.726 A:middle
"Hey, I want to support
this feature."

00:28:35.536 --> 00:28:38.186 A:middle
So I need to give it a
restore identifier and I

00:28:38.186 --> 00:28:40.016 A:middle
like to just do something
descriptive here,

00:28:40.016 --> 00:28:42.246 A:middle
something like heart
rate central

00:28:42.396 --> 00:28:43.916 A:middle
since this is a central
manager we're using

00:28:43.916 --> 00:28:45.086 A:middle
to find heart rate devices.

00:28:45.236 --> 00:28:47.066 A:middle
You can name it whatever
you want.

00:28:47.286 --> 00:28:49.126 A:middle
The only thing that you
need to be aware of is

00:28:49.226 --> 00:28:51.916 A:middle
that it should be unique
within your application.

00:28:52.346 --> 00:28:55.366 A:middle
If you give two managers
the same restore identifier,

00:28:55.706 --> 00:28:57.416 A:middle
both the system and
your app is--

00:28:57.416 --> 00:28:59.216 A:middle
aren't going to able
to know which is which.

00:28:59.986 --> 00:29:02.416 A:middle
OK, so now, we've opted-in.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:59.986 --> 00:29:02.416 A:middle
OK, so now, we've opted-in.

00:29:02.416 --> 00:29:04.956 A:middle
And I said, the second thing
that we needed to do was

00:29:04.956 --> 00:29:06.556 A:middle
to implement our
new delegate method.

00:29:06.956 --> 00:29:10.566 A:middle
And that delegate method is
central manager will restore

00:29:10.566 --> 00:29:10.976 A:middle
a state.

00:29:12.036 --> 00:29:15.166 A:middle
When the system is persisting
some sort of long-term action

00:29:15.166 --> 00:29:16.786 A:middle
on your behalf like we
talked about earlier

00:29:17.126 --> 00:29:19.176 A:middle
and something happens
that we decide

00:29:19.176 --> 00:29:20.356 A:middle
to re-launch your application,

00:29:21.096 --> 00:29:23.946 A:middle
this is the very first delegate
method that will be called.

00:29:23.996 --> 00:29:27.076 A:middle
Let me reiterate because
this is important.

00:29:27.236 --> 00:29:29.336 A:middle
This is the very
first delegate method.

00:29:29.466 --> 00:29:31.016 A:middle
No longer is it didUpdateState.

00:29:31.016 --> 00:29:33.966 A:middle
If you are restored, you
will first get a call

00:29:33.966 --> 00:29:37.356 A:middle
to will restore state and
that's your application's chance

00:29:37.476 --> 00:29:40.926 A:middle
to bring itself back up to
speed with what has been going

00:29:40.926 --> 00:29:44.086 A:middle
on in the system because it
has been gone, it doesn't know.

00:29:44.936 --> 00:29:48.026 A:middle
So, we're going to get back
a variety of things in this.

00:29:48.026 --> 00:29:51.166 A:middle
And the first thing that
we'll do in this application,

00:29:51.166 --> 00:29:52.056 A:middle
we're always scanning.

00:29:52.386 --> 00:29:54.656 A:middle
So we are scanning
from the background.

00:29:54.766 --> 00:29:56.326 A:middle
When our application
got terminated,

00:29:56.326 --> 00:29:57.216 A:middle
we are still scanning.

00:29:57.496 --> 00:29:58.506 A:middle
The system stepped in

00:29:58.506 --> 00:29:59.976 A:middle
and continued scanning
in our behalf.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:00.526 --> 00:30:01.636 A:middle
So now, when we're coming back,

00:30:01.996 --> 00:30:03.216 A:middle
that scanning is
still happening.

00:30:03.376 --> 00:30:06.356 A:middle
So, we can see the services
that we're scanning for

00:30:06.816 --> 00:30:09.416 A:middle
and the scan options that we
provided to the scan call.

00:30:10.236 --> 00:30:13.416 A:middle
Again, in the case of this app,
since we're always scanning

00:30:13.416 --> 00:30:14.126 A:middle
and we're always scanning

00:30:14.126 --> 00:30:17.256 A:middle
for the same thing this is
already kind of expected.

00:30:17.346 --> 00:30:19.546 A:middle
We don't really need to
do anything with this.

00:30:20.136 --> 00:30:24.336 A:middle
The next thing that we're
going to back is a list of all

00:30:24.336 --> 00:30:26.726 A:middle
of the devices that we
had tried to connect

00:30:26.756 --> 00:30:28.246 A:middle
to or were connected to.

00:30:28.816 --> 00:30:33.016 A:middle
So, in this situation we
actually do care about these

00:30:33.016 --> 00:30:36.686 A:middle
because in this app once we find
a device we add it to our list

00:30:36.686 --> 00:30:39.186 A:middle
of Heart Rate devices because we
need to keep a reference to it.

00:30:39.646 --> 00:30:43.456 A:middle
So, here we're coming back
starting up with devices

00:30:43.456 --> 00:30:44.786 A:middle
that we may already
be connected to.

00:30:44.856 --> 00:30:47.366 A:middle
So, they again we need to
keep a reference to them

00:30:47.676 --> 00:30:49.426 A:middle
and they're going
to go on our list.

00:30:50.996 --> 00:30:53.106 A:middle
So, we just go through
any peripherals

00:30:53.106 --> 00:30:54.846 A:middle
that were restored
with, go right back

00:30:54.846 --> 00:30:57.866 A:middle
into that Heart Rate Peripheral
list and we set the delegate.

00:30:59.546 --> 00:31:01.756 A:middle
Now, for some of your
applications this might be

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:59.546 --> 00:31:01.756 A:middle
Now, for some of your
applications this might be

00:31:01.756 --> 00:31:04.166 A:middle
enough, really simple we
haven't done a lot here

00:31:04.276 --> 00:31:07.216 A:middle
but there are two
other things that--

00:31:07.796 --> 00:31:09.716 A:middle
and one in particular
that you really should

00:31:09.716 --> 00:31:10.496 A:middle
at least think about.

00:31:10.986 --> 00:31:12.956 A:middle
And the next thing that
I want to take a look

00:31:12.956 --> 00:31:16.256 A:middle
at is our initialization
process for this application

00:31:16.706 --> 00:31:19.556 A:middle
because before we started
supporting this feature,

00:31:19.726 --> 00:31:22.176 A:middle
every time our application
started up we'd be starting

00:31:22.176 --> 00:31:23.426 A:middle
up with a clean slate.

00:31:24.086 --> 00:31:27.306 A:middle
Now that we support restoration,
we might be getting restored

00:31:27.306 --> 00:31:28.656 A:middle
with stuff that's
still happening

00:31:28.656 --> 00:31:30.096 A:middle
on our behalf in this system.

00:31:30.666 --> 00:31:32.656 A:middle
So, we're going to go to a
Data Update State Method here

00:31:33.096 --> 00:31:35.556 A:middle
and pretend that we've
just been restored.

00:31:35.906 --> 00:31:38.026 A:middle
So, we've gotten that call
to Will Restore State.

00:31:38.766 --> 00:31:40.976 A:middle
So, as we saw before
when power goes

00:31:40.976 --> 00:31:43.526 A:middle
on the first we do
is start scanning.

00:31:44.706 --> 00:31:47.146 A:middle
If we've been restored
we're already scanning,

00:31:47.396 --> 00:31:49.216 A:middle
in this situation calling

00:31:49.216 --> 00:31:51.216 A:middle
up one more time isn't really
going to hurt anything.

00:31:51.216 --> 00:31:52.996 A:middle
It'll actually be
optimized a way anyway

00:31:52.996 --> 00:31:55.006 A:middle
because we're providing
the exact same parameters

00:31:55.006 --> 00:31:56.846 A:middle
as we were-- as we're
already scanning with.

00:31:57.296 --> 00:31:58.766 A:middle
So, it's OK to leave
it, we don't need

00:31:58.766 --> 00:31:59.716 A:middle
to get too tricky here.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:00.406 --> 00:32:03.256 A:middle
But the next thing
that we want to do is

00:32:03.256 --> 00:32:06.356 A:middle
because we may have been
restored with those peripherals,

00:32:06.786 --> 00:32:09.496 A:middle
we're going to take
a look and see,

00:32:10.096 --> 00:32:12.176 A:middle
do I already have
connected peripherals.

00:32:12.416 --> 00:32:14.226 A:middle
So, I might not-- like I
said, we might not be starting

00:32:14.226 --> 00:32:15.296 A:middle
with that clean slate anymore.

00:32:15.296 --> 00:32:16.766 A:middle
So, we're going to
look through our list

00:32:16.766 --> 00:32:17.646 A:middle
of Heart Rate peripherals

00:32:17.646 --> 00:32:19.766 A:middle
and see "Am I connected
to this device?"

00:32:21.106 --> 00:32:24.726 A:middle
And now, if we really want
to be robust which I do

00:32:24.726 --> 00:32:26.796 A:middle
because I'm trying to set a good
example here for all of you,

00:32:27.526 --> 00:32:30.816 A:middle
we could've have gone away
at any point during that kind

00:32:30.816 --> 00:32:33.136 A:middle
of initialization
discovery process that we do

00:32:33.136 --> 00:32:34.366 A:middle
when we connect to a device.

00:32:34.756 --> 00:32:37.056 A:middle
So, we need to be
able to handle that

00:32:37.226 --> 00:32:39.196 A:middle
but it's really--
really quite simple.

00:32:39.236 --> 00:32:41.626 A:middle
So, the first thing that we'll
do is we'll look and we're going

00:32:41.626 --> 00:32:43.906 A:middle
to see have we discovered
that Heart Rate Service.

00:32:44.976 --> 00:32:47.636 A:middle
If not, that's our starting
point we just got something go

00:32:47.636 --> 00:32:49.576 A:middle
discover that service
and everything will kind

00:32:49.576 --> 00:32:50.826 A:middle
of fall back through
that state machine.

00:32:52.026 --> 00:32:53.626 A:middle
Next, we're going
to look and see, OK,

00:32:53.626 --> 00:32:56.406 A:middle
have we discovered the Heart
Rate measurement characteristic?

00:32:56.686 --> 00:32:59.646 A:middle
Again, if not, that's where we
know we need to begin by trying

00:32:59.646 --> 00:33:00.756 A:middle
to discover that characteristic.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:59.646 --> 00:33:00.756 A:middle
to discover that characteristic.

00:33:01.406 --> 00:33:05.026 A:middle
And finally, we're going to
look and see, are we subscribed

00:33:05.026 --> 00:33:06.416 A:middle
for updates on that
characteristic?

00:33:06.876 --> 00:33:08.696 A:middle
And if we are, we're done.

00:33:08.996 --> 00:33:11.986 A:middle
We don't need to do anything
else, we've done restored,

00:33:12.106 --> 00:33:14.186 A:middle
we're still connected to
that Heart Rate device

00:33:14.186 --> 00:33:16.636 A:middle
and we're still subscribed
in our app as back

00:33:16.636 --> 00:33:17.626 A:middle
up to speed with everything.

00:33:17.826 --> 00:33:19.176 A:middle
It's just got away for updates.

00:33:20.246 --> 00:33:23.066 A:middle
Now, there-- may be one more
thing that you need to consider

00:33:23.506 --> 00:33:26.026 A:middle
for those of you who
have multiple managers

00:33:26.326 --> 00:33:29.476 A:middle
or maybe you have a manager
that isn't always around.

00:33:29.476 --> 00:33:32.106 A:middle
So, you instantiate it sometimes
in your app and get rid of it.

00:33:32.386 --> 00:33:36.196 A:middle
You might be wondering, this
all looks great but if I have

00:33:36.246 --> 00:33:39.606 A:middle
to instantiate my manager
in order to restore it,

00:33:39.756 --> 00:33:42.826 A:middle
how do I know what manager
I need to instantiate?

00:33:43.736 --> 00:33:44.456 A:middle
Very good question.

00:33:45.626 --> 00:33:48.496 A:middle
And the answer to that is in
your application delegate,

00:33:48.596 --> 00:33:51.006 A:middle
in this did finish
launching with options method.

00:33:51.646 --> 00:33:53.416 A:middle
Because when we're
relaunching you,

00:33:53.826 --> 00:33:57.236 A:middle
we will give you
back the list of all

00:33:57.236 --> 00:34:00.306 A:middle
of the identifiers representing
the restored managers

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:57.236 --> 00:34:00.306 A:middle
of the identifiers representing
the restored managers

00:34:00.306 --> 00:34:03.296 A:middle
that we've been keeping track
off for you in this system.

00:34:03.796 --> 00:34:07.006 A:middle
So, you can see that you can
retrieve all the identifiers

00:34:07.006 --> 00:34:08.666 A:middle
for the peripheral
managers that you were using

00:34:08.666 --> 00:34:11.106 A:middle
at the time you went away
and the central managers.

00:34:11.726 --> 00:34:14.126 A:middle
In this application,
we don't care again

00:34:14.286 --> 00:34:15.295 A:middle
about peripheral managers

00:34:15.295 --> 00:34:17.085 A:middle
as we're only using
a central manager.

00:34:17.916 --> 00:34:20.206 A:middle
And we're going to go through
and what you need to do

00:34:20.206 --> 00:34:23.636 A:middle
at this point is tell
your application, "Hey,

00:34:23.746 --> 00:34:26.315 A:middle
these are the managers that
I need to reinstantiate.

00:34:26.376 --> 00:34:30.536 A:middle
If you don't reinstantiate a
manager that is being preserved

00:34:30.536 --> 00:34:33.505 A:middle
for you in the system, after
a reasonable amount of time,

00:34:33.505 --> 00:34:35.085 A:middle
the system is going
to assume that, "Hey,

00:34:35.085 --> 00:34:37.466 A:middle
he must not want this
anymore and we're going

00:34:37.466 --> 00:34:38.226 A:middle
to clean it up for you."

00:34:38.335 --> 00:34:41.466 A:middle
So, any long term actions
that was still performing,

00:34:41.726 --> 00:34:43.446 A:middle
those will stop at
that point in time.

00:34:43.876 --> 00:34:46.456 A:middle
In the case of this app, we
have been lucky there's nothing

00:34:46.456 --> 00:34:49.206 A:middle
for us to here because like
I said we have one manager

00:34:49.286 --> 00:34:51.106 A:middle
and it's around for the
lifetime of the application.

00:34:52.235 --> 00:34:56.406 A:middle
So, it's a-- this is pretty
simple, just a recap, we've--

00:34:56.545 --> 00:34:58.986 A:middle
the first thing that we did was
look at our central manager,

00:34:58.986 --> 00:35:00.906 A:middle
we changed the initialization
call

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:58.986 --> 00:35:00.906 A:middle
we changed the initialization
call

00:35:00.906 --> 00:35:03.096 A:middle
to provide a restore
identifier for it.

00:35:03.626 --> 00:35:07.326 A:middle
We implemented that single new
delegate method will restore

00:35:07.326 --> 00:35:10.146 A:middle
state which gives our
application a chance to kind

00:35:10.146 --> 00:35:12.976 A:middle
of get back into sync with what
has been going on in the system.

00:35:12.976 --> 00:35:14.406 A:middle
And then we took at look

00:35:14.406 --> 00:35:17.286 A:middle
at our initialization
process and did update state.

00:35:17.566 --> 00:35:19.246 A:middle
And we made sure to be able to--

00:35:19.246 --> 00:35:21.146 A:middle
that we're able to
handle possibly starting

00:35:21.146 --> 00:35:23.796 A:middle
up with devices that
we're already connected.

00:35:23.956 --> 00:35:27.966 A:middle
And I also show you guys how
to handle the possibility

00:35:27.966 --> 00:35:29.306 A:middle
where you have multiple--

00:35:29.456 --> 00:35:31.006 A:middle
multiple managers
being restored.

00:35:32.556 --> 00:35:34.476 A:middle
So, that's it, hopefully
you agree

00:35:34.476 --> 00:35:36.896 A:middle
that there's not a whole
lot of code involved here.

00:35:36.986 --> 00:35:39.566 A:middle
This isn't as complicated
as it may have seen.

00:35:39.956 --> 00:35:42.246 A:middle
And, you know, with this
little amount of change

00:35:42.246 --> 00:35:44.046 A:middle
to our application, we
now don't have to worry

00:35:44.046 --> 00:35:45.346 A:middle
about being killed
in the background.

00:35:46.736 --> 00:35:48.606 A:middle
So, I'd like to invite
Renaud back up here.

00:35:48.606 --> 00:35:51.126 A:middle
And he's going to talk to you

00:35:52.206 --> 00:35:55.516 A:middle
about the great new built
in services in iOS 7.

00:35:55.846 --> 00:35:58.746 A:middle
>> So, Bluetooth Low Energy has
been around for a few years now.

00:35:58.836 --> 00:36:00.466 A:middle
Four years if I count correctly.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:58.836 --> 00:36:00.466 A:middle
Four years if I count correctly.

00:36:01.026 --> 00:36:02.466 A:middle
And as you see you guys come up,

00:36:02.466 --> 00:36:04.286 A:middle
we start our profiles
already for it.

00:36:04.286 --> 00:36:07.326 A:middle
And we feel the technology
is mature enough now

00:36:07.326 --> 00:36:10.406 A:middle
and our stack is mature enough
that we can make this directly

00:36:10.406 --> 00:36:13.326 A:middle
into the system, and that's what
we're going to do with iOS 7.

00:36:15.356 --> 00:36:16.716 A:middle
So, what did we do?

00:36:16.716 --> 00:36:21.226 A:middle
So, first of all we implemented
some services when we act

00:36:21.226 --> 00:36:24.216 A:middle
as a GATT client and
this is basically a HID

00:36:24.216 --> 00:36:26.726 A:middle
Over GATT Profile as we
talked about this morning

00:36:26.776 --> 00:36:27.946 A:middle
in the accessory session.

00:36:27.946 --> 00:36:30.656 A:middle
The HID Over GATT Profile

00:36:30.686 --> 00:36:33.466 A:middle
which is a bad name
implements these free services.

00:36:33.466 --> 00:36:35.786 A:middle
These are the HID service,
the battery service

00:36:35.786 --> 00:36:37.336 A:middle
and the Device Information
service.

00:36:38.026 --> 00:36:40.266 A:middle
What's special about that
and the fact that it's built

00:36:40.266 --> 00:36:42.426 A:middle
into a system is
that it works just

00:36:42.426 --> 00:36:43.986 A:middle
like Bluetooth Classic devices.

00:36:44.426 --> 00:36:47.446 A:middle
So, you will be able to discover
Bluetooth flow energy HID

00:36:47.446 --> 00:36:49.706 A:middle
devices directly from the
Bluetooth settings pane

00:36:49.706 --> 00:36:51.826 A:middle
like a Bluetooth
Classic would be.

00:36:52.466 --> 00:36:55.706 A:middle
And once you are paired with
Bluetooth Energy HID Device,

00:36:55.766 --> 00:36:58.276 A:middle
iOS will automatically manage
the connection and reconnect

00:36:58.276 --> 00:37:02.826 A:middle
to it if the connection goes
away therefore giving this

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:36:58.276 --> 00:37:02.826 A:middle
to it if the connection goes
away therefore giving this

00:37:02.826 --> 00:37:05.276 A:middle
illusion that it works just
like a normal Bluetooth device

00:37:05.276 --> 00:37:06.676 A:middle
that customers are used to.

00:37:07.026 --> 00:37:09.696 A:middle
So, that's what we use
on the GATT client side.

00:37:10.996 --> 00:37:14.156 A:middle
But we have also interesting
things on the GATT server side.

00:37:14.156 --> 00:37:17.076 A:middle
So, if you connect your
accessory to an iOS device

00:37:17.076 --> 00:37:19.426 A:middle
and you implements
have GATT clients roll.

00:37:19.786 --> 00:37:22.906 A:middle
And you discover services on an
iOS device you will now be able

00:37:22.906 --> 00:37:24.606 A:middle
to see these services
implemented.

00:37:24.606 --> 00:37:27.236 A:middle
And first of all we
have the battery service

00:37:27.416 --> 00:37:30.436 A:middle
which is trivial, I'm not
going to spend much time on it.

00:37:31.606 --> 00:37:33.366 A:middle
We also implemented the
current time service

00:37:33.366 --> 00:37:37.826 A:middle
which is a nifty service if your
accessory requires an accurate

00:37:37.826 --> 00:37:40.426 A:middle
source of time, we provide
accurate time and date

00:37:40.426 --> 00:37:41.856 A:middle
and the time zone information.

00:37:42.316 --> 00:37:45.856 A:middle
So, for example, things
like watches can use that.

00:37:47.986 --> 00:37:50.156 A:middle
But there's one more
thing an iOS dream,

00:37:50.156 --> 00:37:51.066 A:middle
I'm saying that on stage.

00:37:53.796 --> 00:37:56.356 A:middle
And this one more thing
is about Notifications.

00:37:56.916 --> 00:37:59.116 A:middle
We've seen especially
in the last year a lot

00:37:59.116 --> 00:38:02.036 A:middle
of accessories going
on the markets,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:59.116 --> 00:38:02.036 A:middle
of accessories going
on the markets,

00:38:02.586 --> 00:38:05.076 A:middle
the so called "Companion
Devices" that are

00:38:05.076 --> 00:38:09.266 A:middle
for example smart watch that
are all about displaying to you

00:38:09.266 --> 00:38:11.016 A:middle
or relaying notifications

00:38:11.016 --> 00:38:13.576 A:middle
that are happening
on your iOS device.

00:38:14.306 --> 00:38:17.626 A:middle
But they all use methods
to access the notifications

00:38:17.626 --> 00:38:19.826 A:middle
that I'm not very good for
your hockey and all that

00:38:19.826 --> 00:38:21.616 A:middle
and you guys probably know
what I'm talking about.

00:38:22.226 --> 00:38:24.246 A:middle
But these are three
other command solutions

00:38:24.246 --> 00:38:25.506 A:middle
that are being used nowadays.

00:38:26.376 --> 00:38:28.296 A:middle
So, first one is the
Message Access Pro--

00:38:28.296 --> 00:38:32.886 A:middle
or the Message Access Profile
also commonly known as MAP

00:38:32.886 --> 00:38:33.946 A:middle
over Bluetooth Classic.

00:38:34.306 --> 00:38:37.696 A:middle
The problem with MAP is that
it was developed originally

00:38:37.696 --> 00:38:39.076 A:middle
for an automative usage.

00:38:39.286 --> 00:38:43.856 A:middle
It was not meant to be used by a
small smart watch on your wrist.

00:38:43.856 --> 00:38:46.596 A:middle
And it actually doesn't--
it's very constraint,

00:38:46.596 --> 00:38:50.766 A:middle
it only does SMS's, MMS's and
E-mails very well, anything else

00:38:50.766 --> 00:38:52.506 A:middle
that you pass of a MAP is ugly

00:38:52.506 --> 00:38:54.396 A:middle
and it's not going
to go over well.

00:38:55.676 --> 00:38:58.516 A:middle
There is also low energy's
profiles that have come

00:38:58.556 --> 00:38:58.906 A:middle
up from the [inaudible]

00:38:58.906 --> 00:39:01.936 A:middle
for example is the Alert
Notification Service.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:58.906 --> 00:39:01.936 A:middle
for example is the Alert
Notification Service.

00:39:02.286 --> 00:39:06.436 A:middle
The problem with it is that
it is very, very limited,

00:39:06.496 --> 00:39:09.356 A:middle
it's very simple and it's too
simple, it's not good enough.

00:39:10.796 --> 00:39:13.206 A:middle
There's also a full solution
that we've seen a lot

00:39:13.206 --> 00:39:16.726 A:middle
which is you guys developed
a custom application tailored

00:39:16.726 --> 00:39:18.246 A:middle
to your specific accessory.

00:39:18.296 --> 00:39:21.246 A:middle
And those problems
are obvious we've--

00:39:21.366 --> 00:39:24.406 A:middle
did this solution as well which
is that when it's heavyweight,

00:39:24.896 --> 00:39:27.346 A:middle
you have to Run a full
iOS app and any point

00:39:27.346 --> 00:39:30.636 A:middle
on the customer's device
which is not very good.

00:39:31.106 --> 00:39:34.006 A:middle
And your data you
are able to send

00:39:34.006 --> 00:39:36.346 A:middle
through this method is also
limited to what the app

00:39:36.346 --> 00:39:38.646 A:middle
and send both allows and
what the customer allows you

00:39:38.646 --> 00:39:40.956 A:middle
that your app to see which
is not much as you may know.

00:39:42.556 --> 00:39:45.576 A:middle
So, all the solutions are not
very good and that's a state

00:39:45.576 --> 00:39:48.116 A:middle
as it is now but we come
up with all solution

00:39:48.116 --> 00:39:50.016 A:middle
that we think you're
going to love.

00:39:50.746 --> 00:39:54.706 A:middle
And the solution we call it
the Apple Notification Center

00:39:54.706 --> 00:39:58.946 A:middle
Service also known as
ANCS, I may say ANCS

00:39:58.946 --> 00:39:59.976 A:middle
in the next few minutes.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:00.846 --> 00:40:03.436 A:middle
This is also a GATT
server service.

00:40:03.436 --> 00:40:05.956 A:middle
So again, if your accessory
connects to the nearest device

00:40:05.956 --> 00:40:07.266 A:middle
and discover services on it,

00:40:07.266 --> 00:40:09.566 A:middle
it will see this service
implemented on it.

00:40:10.356 --> 00:40:14.346 A:middle
It is Apple's specific uses
on [inaudible] 128 bits UUIDs.

00:40:14.986 --> 00:40:18.596 A:middle
And it basically allows you
to be notified about any kind

00:40:18.596 --> 00:40:19.586 A:middle
of event on your phone.

00:40:20.066 --> 00:40:22.826 A:middle
And that's includes all the
phone functionality events,

00:40:22.826 --> 00:40:25.786 A:middle
for example your incoming
calls and your voice mails.

00:40:26.446 --> 00:40:30.116 A:middle
It notifies you about your IMs
and all the messages you can get

00:40:30.116 --> 00:40:31.796 A:middle
for Facebook or anything else.

00:40:32.616 --> 00:40:33.796 A:middle
It notifies you about calendar.

00:40:33.796 --> 00:40:35.156 A:middle
For example if you are

00:40:35.156 --> 00:40:37.976 A:middle
in 5 minutes it will
be carried over--

00:40:37.976 --> 00:40:39.896 A:middle
this information would be
carried over this service.

00:40:40.526 --> 00:40:41.966 A:middle
And what I'm getting
at basically is

00:40:41.966 --> 00:40:43.676 A:middle
that I need notification

00:40:43.676 --> 00:40:46.806 A:middle
and notification center will
be carried over this service.

00:40:46.806 --> 00:40:49.266 A:middle
There's no preferential
treatment, anything which is

00:40:49.266 --> 00:40:52.126 A:middle
in notification center will
be sent over this service.

00:40:52.126 --> 00:40:55.676 A:middle
You have full access to anything
that's will be notifiable

00:40:55.676 --> 00:40:57.516 A:middle
on iOS by default.

00:40:57.986 --> 00:41:03.506 A:middle
And again, like the HID service
I just talked to you about,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:57.986 --> 00:41:03.506 A:middle
And again, like the HID service
I just talked to you about,

00:41:03.506 --> 00:41:07.336 A:middle
once an accessory has been
recognized as using ANCS,

00:41:07.336 --> 00:41:10.336 A:middle
iOS would automatically
manage a connection

00:41:10.336 --> 00:41:11.146 A:middle
and reconnect for you.

00:41:11.146 --> 00:41:13.026 A:middle
So, your app doesn't
have to do that anymore.

00:41:13.616 --> 00:41:14.586 A:middle
We will do that for you.

00:41:14.856 --> 00:41:18.396 A:middle
So, detailed specification
will be posted

00:41:18.396 --> 00:41:19.646 A:middle
on the developers portal soon.

00:41:19.646 --> 00:41:21.246 A:middle
We still have a few
things to work-out.

00:41:21.626 --> 00:41:24.116 A:middle
But look forward to that and,
well, [inaudible] is going

00:41:24.116 --> 00:41:25.586 A:middle
to be out really soon.

00:41:26.296 --> 00:41:29.636 A:middle
But before I finish that,
I just want to give you

00:41:29.636 --> 00:41:32.366 A:middle
like a sneak peek of the
mechanisms on who it works

00:41:32.366 --> 00:41:34.356 A:middle
and you will see it's really
simple and straightforward.

00:41:34.356 --> 00:41:35.476 A:middle
It's not complex at all.

00:41:35.886 --> 00:41:37.976 A:middle
But it [inaudible]
very powerful.

00:41:38.836 --> 00:41:40.236 A:middle
So, let's take the used case

00:41:40.236 --> 00:41:43.106 A:middle
of an iPhone connected
to a smart watch.

00:41:43.106 --> 00:41:46.416 A:middle
For example, in this case
a very blue smart watch.

00:41:47.066 --> 00:41:49.676 A:middle
And the user just
received a new iMessage.

00:41:49.676 --> 00:41:55.276 A:middle
Well, we will send a
message over ANCS telling you

00:41:55.276 --> 00:41:58.296 A:middle
that the user just received
a so-called new social

00:41:58.296 --> 00:42:02.236 A:middle
notification and we will create
a UUID for this notification

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:58.296 --> 00:42:02.236 A:middle
notification and we will create
a UUID for this notification

00:42:02.236 --> 00:42:03.656 A:middle
which is going to
[inaudible] a handle

00:42:03.656 --> 00:42:05.386 A:middle
to retrieve more
information about it.

00:42:05.786 --> 00:42:07.386 A:middle
In this case, we just use one.

00:42:08.096 --> 00:42:11.396 A:middle
And the accessory as supposedly
to retrieve more information

00:42:11.396 --> 00:42:13.966 A:middle
about this notification which
is exactly what it does now

00:42:14.476 --> 00:42:17.336 A:middle
where it can go back
and ask for attributes.

00:42:17.696 --> 00:42:20.686 A:middle
In this example, it wants
the title and message.

00:42:20.686 --> 00:42:22.236 A:middle
There's a list of
attribute to provide.

00:42:22.236 --> 00:42:23.636 A:middle
In this case, we just want two.

00:42:24.466 --> 00:42:27.906 A:middle
And iPhone will provide all this
information to your accessory.

00:42:27.906 --> 00:42:30.876 A:middle
In this case it's the title
is actually the sender

00:42:30.876 --> 00:42:33.926 A:middle
of the iMessage and the
message is the body of iMessage

00:42:33.926 --> 00:42:36.656 A:middle
and it's Jason because
Jason is part is looking

00:42:36.656 --> 00:42:37.726 A:middle
to get beers pretty soon.

00:42:38.476 --> 00:42:41.996 A:middle
Of course at this point
your accessory is free

00:42:41.996 --> 00:42:43.006 A:middle
to do whatever it want.

00:42:43.006 --> 00:42:47.636 A:middle
You can blink an LED or you
can displays the entirety

00:42:47.636 --> 00:42:49.006 A:middle
of the message and
a big display.

00:42:49.006 --> 00:42:50.756 A:middle
Whatever you accessory
implements,

00:42:51.276 --> 00:42:52.456 A:middle
it's up to you at this point.

00:42:54.026 --> 00:42:55.956 A:middle
Later on when the
iMessages is read

00:42:55.956 --> 00:42:59.106 A:middle
or the notification is
dismissed on the device,

00:42:59.106 --> 00:43:00.766 A:middle
we will also notify
the accessory

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:59.106 --> 00:43:00.766 A:middle
we will also notify
the accessory

00:43:00.766 --> 00:43:04.206 A:middle
that this notification is
now invalid and you're free

00:43:04.206 --> 00:43:06.066 A:middle
to dismiss the alert
on your device as well.

00:43:06.066 --> 00:43:07.536 A:middle
So, a full synchronization
mechanism

00:43:07.536 --> 00:43:09.866 A:middle
between notification
center and all these events

00:43:10.306 --> 00:43:13.846 A:middle
and your accessory and
as pretty much ANCS

00:43:13.846 --> 00:43:16.466 A:middle
and this was just a sneak
peek, it's capable of much,

00:43:16.466 --> 00:43:19.226 A:middle
much more-- it's very
powerful, very simple as well.

00:43:19.226 --> 00:43:22.086 A:middle
We try to keep it simple
and look forward to that

00:43:22.086 --> 00:43:26.376 A:middle
onto the developer
portals again.

00:43:27.066 --> 00:43:30.516 A:middle
I just want to quickly finish
by some tips and best practices

00:43:30.516 --> 00:43:34.686 A:middle
that I've come up by monitoring
the developer forums and,

00:43:34.686 --> 00:43:36.336 A:middle
you know, and getting
your radars

00:43:36.336 --> 00:43:39.716 A:middle
because radar [inaudible]
is not a black hole as--

00:43:40.386 --> 00:43:43.466 A:middle
I assure you, all the radar you
filed they're going all queue

00:43:43.466 --> 00:43:44.736 A:middle
and we looked at
everyone of them.

00:43:45.356 --> 00:43:46.366 A:middle
So, here are some few tips

00:43:46.366 --> 00:43:49.186 A:middle
and best practices
some common mishaps

00:43:49.186 --> 00:43:51.066 A:middle
and pitfalls you guys
tend to fall in to.

00:43:51.066 --> 00:43:54.836 A:middle
So, I just-- I just want
you to keep track of that.

00:43:55.396 --> 00:43:57.806 A:middle
So, first of all, like we said
before, CoreBluetooth needs

00:43:57.806 --> 00:43:59.436 A:middle
to know if you intend
CBPeripherals.

00:43:59.436 --> 00:44:00.936 A:middle
Please keep a reference to them.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:59.436 --> 00:44:00.936 A:middle
Please keep a reference to them.

00:44:01.706 --> 00:44:03.756 A:middle
If a CBPeripheral gets locked,

00:44:03.756 --> 00:44:06.546 A:middle
we will assume you are
not interested in it

00:44:07.056 --> 00:44:08.886 A:middle
and the system will take action

00:44:08.886 --> 00:44:11.286 A:middle
in your behalf including
disconnecting the peripheral

00:44:11.286 --> 00:44:15.936 A:middle
implicitly because we do not
want to making that connection

00:44:15.936 --> 00:44:18.476 A:middle
that is not used by
your system at all.

00:44:18.476 --> 00:44:20.846 A:middle
So, keep a reference, it
is something that a lot

00:44:20.846 --> 00:44:22.316 A:middle
of you probably made
the mistake,

00:44:22.316 --> 00:44:23.616 A:middle
it's the first time
you use CoreBluetooth.

00:44:25.766 --> 00:44:28.966 A:middle
Scan request and connection
request never time out

00:44:28.966 --> 00:44:30.256 A:middle
and you needed to
call them once.

00:44:30.256 --> 00:44:31.616 A:middle
So, it's like an
elevator button.

00:44:31.616 --> 00:44:33.366 A:middle
You don't need to press
them multiple times.

00:44:33.366 --> 00:44:34.556 A:middle
It's not going to go any faster.

00:44:35.056 --> 00:44:36.746 A:middle
And actually it might
be detriment

00:44:36.746 --> 00:44:38.146 A:middle
or to the speed of your action.

00:44:38.146 --> 00:44:41.166 A:middle
So, just call it once and
everything will work fine.

00:44:41.166 --> 00:44:42.226 A:middle
We'll take care of
the rest for you.

00:44:43.516 --> 00:44:48.086 A:middle
It wasn't explicit before
but now it's explicit.

00:44:48.086 --> 00:44:51.206 A:middle
CBPeripherals and CBCentrals
conform to NSCopying.

00:44:51.616 --> 00:44:55.206 A:middle
And actually most CB objects can
be used as NS dictionary keys.

00:44:55.546 --> 00:44:58.156 A:middle
We've seen a lot of you
guys using an indirect map

00:44:58.156 --> 00:45:00.276 A:middle
between UUIDs and CB
objects and all of that.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:58.156 --> 00:45:00.276 A:middle
between UUIDs and CB
objects and all of that.

00:45:00.886 --> 00:45:02.936 A:middle
Just use the CB objects
as dictionary keys.

00:45:02.936 --> 00:45:04.206 A:middle
It simplifies a lot
of the codes.

00:45:04.206 --> 00:45:06.636 A:middle
I know I simplify a lot
of my code by doing that.

00:45:06.906 --> 00:45:10.236 A:middle
So, please just use that as
keys and you'll see it's great.

00:45:12.116 --> 00:45:15.126 A:middle
Please, please do not touch
the Client Configuration

00:45:15.126 --> 00:45:17.936 A:middle
Characteristic Descriptor
directly.

00:45:17.936 --> 00:45:20.836 A:middle
This is not going to work

00:45:21.066 --> 00:45:23.076 A:middle
and you guys may
already have tried that.

00:45:23.076 --> 00:45:23.856 A:middle
These are not going to work.

00:45:23.856 --> 00:45:26.496 A:middle
This is going to break the
state in the application.

00:45:26.496 --> 00:45:30.286 A:middle
So, we have an API for that
whether set notify value

00:45:30.726 --> 00:45:32.836 A:middle
for descriptor which--
for characteristic, sorry,

00:45:33.396 --> 00:45:35.846 A:middle
which is much easier
to use and it's going

00:45:35.846 --> 00:45:37.966 A:middle
to work instead of that.

00:45:38.916 --> 00:45:42.246 A:middle
Please, please do not game
the background mechanisms.

00:45:42.896 --> 00:45:43.686 A:middle
We are not stupid.

00:45:43.686 --> 00:45:46.376 A:middle
We know it's the kind of
tricks you guys are using

00:45:46.976 --> 00:45:50.186 A:middle
and if you start using them
or you continue using them,

00:45:50.186 --> 00:45:51.846 A:middle
you're going to get
in trouble eventually.

00:45:51.846 --> 00:45:55.376 A:middle
And we hope that we-- what we
introduce today with iOS 7,

00:45:55.926 --> 00:45:58.086 A:middle
you will have all the
tools and APIs especially

00:45:58.086 --> 00:45:59.776 A:middle
with application restoration,

00:45:59.776 --> 00:46:02.136 A:middle
things that Jason
have told about.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:45:59.776 --> 00:46:02.136 A:middle
things that Jason
have told about.

00:46:02.136 --> 00:46:05.896 A:middle
You have all to the
tools for you to not have

00:46:05.896 --> 00:46:09.426 A:middle
to use these nasty
tricks that nobody likes.

00:46:09.426 --> 00:46:10.196 A:middle
We don't like them.

00:46:10.196 --> 00:46:10.886 A:middle
You don't like them.

00:46:10.886 --> 00:46:13.036 A:middle
We know we've provided
you everything.

00:46:13.036 --> 00:46:15.426 A:middle
We hope that that you don't
need to do that anymore.

00:46:17.686 --> 00:46:21.686 A:middle
And that's it for my tips
and best practices session.

00:46:21.686 --> 00:46:24.346 A:middle
And I'm going call back Brian
to have the final words.

00:46:25.406 --> 00:46:26.926 A:middle
>> Pretty amazing stuff, right?

00:46:26.926 --> 00:46:31.856 A:middle
I mean this-- this in my mind
makes CoreBluetooth really the

00:46:31.856 --> 00:46:35.516 A:middle
launching platform for
really major initiates

00:46:35.596 --> 00:46:36.666 A:middle
in Bluetooth Low Energy.

00:46:36.666 --> 00:46:40.116 A:middle
I'm thrilled that we've
finally got this stuff in there.

00:46:40.536 --> 00:46:43.926 A:middle
And with the stuff around
restoration, you know,

00:46:43.926 --> 00:46:49.296 A:middle
preservation and restoration,
it completely opens up markets

00:46:49.386 --> 00:46:53.626 A:middle
that we know that you guys
have tried to participate in.

00:46:54.056 --> 00:46:57.806 A:middle
But now from a consumer's
perspective it should work all

00:46:57.806 --> 00:46:58.296 A:middle
the time.

00:46:58.486 --> 00:47:00.996 A:middle
It should be 100
percent up all the time.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:46:58.486 --> 00:47:00.996 A:middle
It should be 100
percent up all the time.

00:47:01.246 --> 00:47:05.266 A:middle
Every time I walk in front of
my home door, it unlocks, right.

00:47:05.266 --> 00:47:07.956 A:middle
Every time that my blood
glucose monitor takes reading,

00:47:08.176 --> 00:47:09.346 A:middle
my phone knows about it.

00:47:09.626 --> 00:47:11.486 A:middle
And it's not going to
work some of the time

00:47:11.486 --> 00:47:12.956 A:middle
and not work the other time.

00:47:13.206 --> 00:47:17.526 A:middle
It's now completely bulletproof,
consumer-ready, you know,

00:47:17.526 --> 00:47:19.596 A:middle
industry leading technology.

00:47:19.596 --> 00:47:21.806 A:middle
And we're super, super
excited to bring it to you.

00:47:21.806 --> 00:47:25.336 A:middle
The other thing around Apple
Notification Center Service,

00:47:25.776 --> 00:47:30.516 A:middle
affectionately called ANCS, is
we feel like that that's going

00:47:30.516 --> 00:47:33.826 A:middle
to make this [inaudible]
products sing and the things

00:47:33.826 --> 00:47:35.756 A:middle
that you guys are going
to be doing with this.

00:47:35.816 --> 00:47:39.696 A:middle
It doesn't matter if it's a
watch like Renaud showed here

00:47:39.896 --> 00:47:44.496 A:middle
or something as simple as
fashion or jewelry that lights

00:47:44.496 --> 00:47:48.096 A:middle
up when you get a text message
from your significant other

00:47:48.336 --> 00:47:51.696 A:middle
or your child, the things
that you guys can make

00:47:51.696 --> 00:47:54.136 A:middle
with these things is
just going to be awesome

00:47:54.136 --> 00:47:55.346 A:middle
and I can't wait to see that.

00:47:56.066 --> 00:47:59.876 A:middle
One thing, I will note on Jason
and Renaud, these guys wrote

00:47:59.876 --> 00:48:02.276 A:middle
in part CoreBluetooth.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:59.876 --> 00:48:02.276 A:middle
in part CoreBluetooth.

00:48:02.276 --> 00:48:06.316 A:middle
So, these, you cannot hear
from anybody more expert

00:48:06.316 --> 00:48:07.826 A:middle
in this particular topics.

00:48:07.826 --> 00:48:10.646 A:middle
And both of them will be
in the lab this afternoon

00:48:10.646 --> 00:48:12.326 A:middle
to answer any questions
you may have.

00:48:12.326 --> 00:48:16.186 A:middle
We also have folks like
Gus [phonetic] is here

00:48:16.186 --> 00:48:18.946 A:middle
who is our senior
engineer for all

00:48:18.946 --> 00:48:20.656 A:middle
of our Bluetooth
server and stack.

00:48:20.896 --> 00:48:24.676 A:middle
Ardy Kumar is here which is
one of our audio experts.

00:48:24.676 --> 00:48:28.926 A:middle
We have you know industry
leading engineering in this area

00:48:28.926 --> 00:48:30.996 A:middle
and they're all here to
answer questions for you.

00:48:30.996 --> 00:48:33.686 A:middle
So, if you do have more
questions definitely come

00:48:33.686 --> 00:48:36.766 A:middle
down into the lab
after this session

00:48:36.766 --> 00:48:38.706 A:middle
and we would love to
help you guys out.

00:48:40.216 --> 00:48:43.526 A:middle
One other question that we get
a lot and I don't have a slide

00:48:43.526 --> 00:48:44.686 A:middle
for it here but I just wanted

00:48:44.686 --> 00:48:48.096 A:middle
to cover it really quick is I
get a lot of people asking me,

00:48:48.096 --> 00:48:52.036 A:middle
"How do I submit apps that
use CoreBluetooth and talk

00:48:52.036 --> 00:48:54.376 A:middle
to Bluetooth Low
Energy hardware?

00:48:54.866 --> 00:48:57.386 A:middle
And so, the App Store
folks have asked me

00:48:57.386 --> 00:48:59.786 A:middle
to just give you a
couple of suggestions.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:49:00.056 --> 00:49:02.766 A:middle
When you submit an app that's
using a Bluetooth Low Energy

00:49:02.766 --> 00:49:04.916 A:middle
device, send the
device in as well.

00:49:05.226 --> 00:49:08.596 A:middle
And when you send that device
in, the extremely explicit

00:49:08.596 --> 00:49:10.746 A:middle
and exactly what
that device does,

00:49:11.066 --> 00:49:13.166 A:middle
you could provide the
services and characteristics

00:49:13.166 --> 00:49:14.646 A:middle
that device implements.

00:49:14.676 --> 00:49:18.016 A:middle
Give it the-- you know describe
exactly what the device does.

00:49:18.226 --> 00:49:19.616 A:middle
How to use that device?

00:49:19.756 --> 00:49:22.606 A:middle
A lot of times we'll get a
device and it's like a big trunk

00:49:22.606 --> 00:49:26.256 A:middle
of plastic and there're not
buttons and it's like, OK,

00:49:26.536 --> 00:49:27.446 A:middle
that's great, you know.

00:49:27.446 --> 00:49:28.686 A:middle
And it goes on a
shelf somewhere.

00:49:28.816 --> 00:49:33.986 A:middle
So, just be explicit in
providing that information to us

00:49:33.986 --> 00:49:35.336 A:middle
when you send those apps.

00:49:35.336 --> 00:49:38.096 A:middle
And if you have more questions
on this, a lot of guys

00:49:38.096 --> 00:49:41.716 A:middle
from our [inaudible] team
will be in the lab as well

00:49:41.716 --> 00:49:43.726 A:middle
to answer some of those
questions in more detail

00:49:43.726 --> 00:49:45.066 A:middle
as much as they possibly can.

00:49:45.666 --> 00:49:49.276 A:middle
As always our Bluetooth
guidelines document is online.

00:49:49.276 --> 00:49:52.966 A:middle
You can search for this pretty
much anywhere and it's available

00:49:52.966 --> 00:49:54.346 A:middle
if you go in our developer site.

00:49:54.486 --> 00:49:56.626 A:middle
It's absolutely super
easy to find.

00:49:56.626 --> 00:49:58.866 A:middle
We constantly keep this updated

00:49:59.146 --> 00:50:01.706 A:middle
and this is being
updated as we speak.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:49:59.146 --> 00:50:01.706 A:middle
and this is being
updated as we speak.

00:50:02.136 --> 00:50:04.416 A:middle
I don't know if an
update is online yet.

00:50:04.416 --> 00:50:06.266 A:middle
Hopefully, it'll
be very, very soon.

00:50:06.536 --> 00:50:08.796 A:middle
And in addition to that,
for the first time,

00:50:09.016 --> 00:50:11.386 A:middle
we now have a CoreBluetooth
programming guide

00:50:11.596 --> 00:50:13.416 A:middle
or reference manual, finally.

00:50:13.416 --> 00:50:15.316 A:middle
It took us awhile
to get this done.

00:50:15.516 --> 00:50:19.016 A:middle
But we have some awesome writers
working on this and I know

00:50:19.016 --> 00:50:22.246 A:middle
that they have a little bit more
work to do to incorporate some

00:50:22.246 --> 00:50:25.516 A:middle
of the new things that
we've implemented in iOS 7.

00:50:25.786 --> 00:50:27.386 A:middle
But this will be available very,

00:50:27.386 --> 00:50:29.716 A:middle
very soon on the
developer portal as well.

00:50:29.716 --> 00:50:32.636 A:middle
So, definitely check it
out as soon it's there.

00:50:32.636 --> 00:50:34.746 A:middle
It's going to be a
huge, huge reference

00:50:34.826 --> 00:50:37.996 A:middle
of you guys not only the
kind of introduce you the lot

00:50:37.996 --> 00:50:40.796 A:middle
of the key concepts that
we brought up today.

00:50:41.096 --> 00:50:43.096 A:middle
But then it'll go into
lot of the reference

00:50:43.096 --> 00:50:45.706 A:middle
around that the actual code
and implementation details.

00:50:45.706 --> 00:50:46.706 A:middle
So, check it out.

00:50:47.386 --> 00:50:51.676 A:middle
For more information, we
have these people who eat

00:50:51.676 --> 00:50:52.566 A:middle
and breathe this stuff.

00:50:52.936 --> 00:50:55.626 A:middle
Craig and Stephen, both
of them are awesome guys.

00:50:55.626 --> 00:50:57.686 A:middle
They love to answer any
questions you may have

00:50:57.686 --> 00:50:59.666 A:middle
around CoreBluetooth or
Bluetooth in general.

00:50:59.976 --> 00:51:02.966 A:middle
We also have the
developer program, DTS.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:50:59.976 --> 00:51:02.966 A:middle
We also have the
developer program, DTS.

00:51:02.966 --> 00:51:05.466 A:middle
It's a little bit more formal.

00:51:05.466 --> 00:51:07.856 A:middle
You're going to get a
guaranteed response with that.

00:51:08.256 --> 00:51:11.846 A:middle
Our developer programs, MFI,
we briefly talk about that

00:51:11.846 --> 00:51:13.136 A:middle
in our session this morning.

00:51:13.446 --> 00:51:16.006 A:middle
You're going to get for-- more
information from those guys

00:51:16.006 --> 00:51:19.786 A:middle
at our MFI web landing
page on the developer site.

00:51:19.786 --> 00:51:23.336 A:middle
In addition of that,
all these other things,

00:51:23.606 --> 00:51:27.856 A:middle
the one thing I want to iterate
right now before we go any

00:51:27.856 --> 00:51:31.976 A:middle
further is right now you guys
having your hands hopefully all

00:51:31.976 --> 00:51:34.556 A:middle
of you have updated
your devices to iOS 7.

00:51:34.556 --> 00:51:36.376 A:middle
You have the new SDK.

00:51:36.376 --> 00:51:37.876 A:middle
You're playing around with
it and you're going to come

00:51:37.876 --> 00:51:39.916 A:middle
to the lab with all
of your code in hand

00:51:40.226 --> 00:51:41.556 A:middle
and work with those on that.

00:51:41.556 --> 00:51:44.276 A:middle
And if you haven't, we're going
to have another lab on Thursday.

00:51:44.276 --> 00:51:46.976 A:middle
So, hopefully that gives you a
couple of more nights to work

00:51:46.976 --> 00:51:48.206 A:middle
through upgrading your code.

00:51:48.616 --> 00:51:49.936 A:middle
But bring that to us,

00:51:50.276 --> 00:51:52.286 A:middle
if for whatever reason
you can't make it,

00:51:52.656 --> 00:51:54.406 A:middle
or even if you can make it

00:51:54.406 --> 00:51:56.416 A:middle
and you find what
you think are bugs,

00:51:56.606 --> 00:51:59.186 A:middle
report those bugs
especially right now.

00:51:59.546 --> 00:52:01.446 A:middle
This is the time to
get those bugs to as

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:51:59.546 --> 00:52:01.446 A:middle
This is the time to
get those bugs to as

00:52:01.446 --> 00:52:04.706 A:middle
so that we can investigate these
issues and get them resolve

00:52:04.706 --> 00:52:05.906 A:middle
as quickly as possible.

00:52:06.176 --> 00:52:10.436 A:middle
And if by the way send an email
to Craig or Stephen as well just

00:52:10.436 --> 00:52:12.996 A:middle
to let them know, hey, I found
this issue, it's the problem.

00:52:13.356 --> 00:52:16.066 A:middle
The developer forums
are both active,

00:52:16.126 --> 00:52:18.036 A:middle
very active for iOS and Mac.

00:52:18.036 --> 00:52:19.796 A:middle
We have a great community
in that space

00:52:19.796 --> 00:52:21.566 A:middle
that you guys are
helping each other

00:52:21.836 --> 00:52:23.286 A:middle
to solve a lot of
these problems.

00:52:23.626 --> 00:52:25.386 A:middle
We personally cannot respond

00:52:25.386 --> 00:52:27.636 A:middle
to everything that's
going on in those forms.

00:52:27.846 --> 00:52:30.606 A:middle
But rest assured we
read every single post.

00:52:30.736 --> 00:52:34.586 A:middle
I personally read every
single post in those spaces.

00:52:34.626 --> 00:52:37.786 A:middle
I can't always respond but
I love hearing the feedback.

00:52:38.086 --> 00:52:41.496 A:middle
And certainly we take all that
information and internalize it.

00:52:41.726 --> 00:52:45.046 A:middle
As far as what's going
on, with other sessions.

00:52:45.046 --> 00:52:47.196 A:middle
There was a session
this morning--

00:52:47.196 --> 00:52:48.516 A:middle
you cannot go back in time.

00:52:48.516 --> 00:52:49.856 A:middle
If you can, good for you.

00:52:50.136 --> 00:52:52.386 A:middle
But if you can't, you
can watch this later.

00:52:52.636 --> 00:52:54.686 A:middle
The WWDC app is making a lot

00:52:54.686 --> 00:52:56.736 A:middle
of these sessions
available almost instantly.

00:52:57.066 --> 00:52:58.576 A:middle
So, definitely go check it out.

00:52:58.876 --> 00:53:01.276 A:middle
And then we didn't talk a
whole lot about proximity.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:52:58.876 --> 00:53:01.276 A:middle
And then we didn't talk a
whole lot about proximity.

00:53:01.486 --> 00:53:03.826 A:middle
Well, because they're talking
about that in Core Location.

00:53:03.886 --> 00:53:06.506 A:middle
We felt like that's a
location services technology

00:53:06.726 --> 00:53:09.016 A:middle
and the Core Location guys
should really go into that.

00:53:09.276 --> 00:53:12.616 A:middle
There is a session on Thursday
that you guys should check out.

00:53:13.356 --> 00:53:16.196 A:middle
So, I want close
was just talking

00:53:16.196 --> 00:53:18.086 A:middle
about these used cases again.

00:53:18.146 --> 00:53:23.156 A:middle
And I want to kind of reiterate
how important we think Bluetooth

00:53:23.156 --> 00:53:28.396 A:middle
Low Energy is to the future
of accessory communications.

00:53:28.396 --> 00:53:31.776 A:middle
I mean all of these used
cases are profoundly important

00:53:31.776 --> 00:53:32.656 A:middle
to the consumer.

00:53:32.996 --> 00:53:35.026 A:middle
And when they have iOS
products in their hand

00:53:35.346 --> 00:53:37.236 A:middle
and it just naturally
communicates

00:53:37.236 --> 00:53:41.036 A:middle
with these devices we really are
starting to realize this concept

00:53:41.036 --> 00:53:42.186 A:middle
of the internet of things.

00:53:42.466 --> 00:53:44.646 A:middle
And it's just incredibly
powerful.

00:53:45.106 --> 00:53:48.326 A:middle
And it's super, super exciting
to be an engineer working

00:53:48.326 --> 00:53:51.686 A:middle
in communications because
of the nature the fact

00:53:51.686 --> 00:53:55.866 A:middle
that we can now truly put a
radio in everything around us

00:53:55.866 --> 00:53:57.366 A:middle
and have it fully integrate

00:53:57.366 --> 00:53:59.856 A:middle
with the consumer's
applications in their devices.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:54:00.296 --> 00:54:03.566 A:middle
And ultimately it means this
idea of connecting the world

00:54:03.566 --> 00:54:05.656 A:middle
that we can connect
all these devices

00:54:05.956 --> 00:54:09.496 A:middle
in this heterogeneous
ecosystem that's just going

00:54:09.496 --> 00:54:12.556 A:middle
to create incredibly profound
experiences for our customers.

00:54:12.856 --> 00:54:15.886 A:middle
So, with that, I'd like to thank
you for coming for our session.

00:54:15.886 --> 00:54:16.636 A:middle
Enjoy WWDC.

00:54:16.636 --> 00:54:18.386 A:middle
We'll see you guys in the lab.

00:54:18.786 --> 00:54:19.806 A:middle
Thanks. [Applause]