Transcript
[ Music ]
[ Applause ]
>> Thank you for joining the
session.
My name is Duy Phan.
I'm here with Yilok and Meghna
to talk to you about what's new
in Core Bluetooth.
I'll start with an introduction.
Then LE 2 Mbps and advertising
extension.
Then provide an overview for
Core Bluetooth for BR/EDR
devices.
Then Core Bluetooth for
dual-mode, user privacy,
developer tools, then wrap up
with a summary.
Let's start with the
introduction.
For those in the audience that's
new to Core Bluetooth, the Core
Bluetooth framework is our
abstraction of the Bluetooth low
energy specification and
hardware.
We provide our developers an
easy and robust way to develop
applications that can interact
with Bluetooth low energy
devices, and since the
introduction of the framework,
we've seen an amazing number of
accessories and applications.
We've seen everything from
health and fitness devices to
indoor locationing and item
finding to creative tools, toys
and accessories for kids, things
for the home, appliances, and
even everyday items like
Bluetooth controlled water
bottles and mugs.
Our developers' creativity and
hard work have really made the
Bluetooth low everything
ecosystem a very vibrant and
innovative space, thank you.
[ Applause ]
But there's more.
There exists an entire class of
Bluetooth devices that are also
thriving and growing, but we
often don't talk about them here
because they don't support the
Core Bluetooth framework.
These are Bluetooth BR/EDR
devices, and they include
accessories like your favorite
audio streaming devices, in-car
entertainment systems with
hands-free calling and various
accessories like mouse and
keyboards and game pads.
What's been missing is a way for
our Core Bluetooth developers to
develop applications that can
interact with these devices.
Until now.
This year we are adding Core
Bluetooth support for BR/EDR
devices.
[ Applause ]
Thank you.
[ Applause ]
This means that Core Bluetooth
can now reach out and interact
with all of your favorite
Bluetooth devices regardless of
what transport they run.
In addition, we added various
dual-mode features, so the two
transport works even better when
they're together.
We hope that our developers will
take advantage of these
features, and we look forward to
seeing all of the new
accessories and applications you
build.
So, this year we really have
three major driving themes.
The first is, as always, to
improve our core technology but
also to protect our user privacy
and enable our developers with
better tools.
Let's get started with
improvements to our core
technology and LE 2 megabits.
LE 2 Mbps is a new feature in
Bluetooth 5.0.
The physical layer rate or radio
rate can increase now from 1 to
2 Mbps between compatible
devices.
This means that with the same
amount of airtime, Core
Bluetooth can now transmit twice
the number of bits, so your
connections are not only faster,
they're also more power
efficient.
This is better yet transparent
to the application.
We will handle all of the link
layer negotiations for you based
on the platform you're on.
But remember, if you're
developing an accessory, your
accessory must also support LE 2
Mbps for this to work.
This is available now starting
with iPhone 8, 8 Plus, iPhone X,
Apple TV 4K, and the Apple Watch
Series 4.
And here I have an illustration
of Bluetooth 1 Mbps in various
modes.
And I've added LE 2 Mbps to show
the [applause], thank you, to
show the leap forward in
performance.
Also new for this year we've
added advertising extension.
Advertising extension is a
Bluetooth 5.0 feature.
It essentially improves upon
three main points for
advertising.
The first is it eases the
congestion on the three
advertising channel by sending a
smaller payload on the
advertising channel, then
jumping to the more spacious
data channel to transmit a much
larger payload.
Up now from 31 to 255 bytes, and
the transmission rate itself can
now be in LE 2 Mbps.
Core Bluetooth will support
extended scan this year.
This means that we can scan now
for the extended advertisements
that I've just mentioned, but we
will only scan for our extended
advertisements that are
transmitted in LE 2 Mbps.
So, if you're developing an
accessory, your accessory must
also support extended
advertisement with LE 2 Mbps.
We now support extended
advertisement payloads up to 124
bytes.
This is four times the amount of
advertisement data that an
accessory can send us today.
This is again transparent to
your application.
You can use the same scan API,
scan filters.
We would scan for both legacy
and extended advertisements.
There's a new API for you to
programmatically query for
platform support, and this is
now supported on iPhone XS and
the new iPad Pro.
Also new for this year we're
going to support extended
connections.
This means that we can make
connections to connectable,
extended advertisements.
Extended connections improve
upon the existing connection
exchange protocol, and I'll
explain how.
Today with Legacy Connections,
the advertiser would advertise a
connectable advertisement.
The scanner would send a
connection identification if it
wants to connect.
There's no ACK for this.
The scanner assumes that the
connection indication reaches
the advertiser.
It then wakes up the host
processor to tell it there's a
new connection.
But the connection indication
may actually not reach the
advertiser because the RF
characteristic of the scanner
and advertiser can differ, and
the RF environment is very
dynamic.
So, because of this, throughout
your day, your whole processor
can be unnecessarily woken up,
training your phone's battery
more while you're using, your
user is using your application
or accessory.
But extended connections improve
upon this.
With extended connections, the
advertiser would advertise a
connectable extended
advertisement.
The scanner would send a
connection request.
The advertiser would send an
explicit connection response,
and only when the scanner
receives this connection
response it will wake the host
processor to tell it there's the
new connection.
In addition, your connection can
also start in LE 2 Mbps,
skipping some of the link layer
negotiation.
And because of this, extended
Connection is more robust and
power efficient.
It is again transparent to your
application if you can call the
same connect API.
It will connect to both Legacy
and Extended Advertisements.
But remember if you're
developing an accessory, your
accessory must also support
connectable extended
advertisements.
There's a new API for you to
programmatically query for
platform support.
This is also available now with
iPhone XS and the new iPad Pro.
I'd like to now hand it off to
Yilok to talk about Core
Bluetooth support for BR/EDR.
Thank you.
[ Applause ]
>> Thanks, Duy.
Hi everyone.
I'm Yilok, and I'm here to
introduce you to you the new
things we've added to Core
Bluetooth for BR/EDR devices.
When we first introduced Core
Bluetooth back in 2012, we
wanted to create an abstraction
layer for you to use what's
called GATT.
Now GATT is a Bluetooth SIG
protocol that is
hierarchy-based, and it consists
if services and characteristics,
and it makes it very easy to
read, write, and be notified of
changes on these
characteristics.
You've shown us that it's
exceptionally easy to make great
products such as heart rate
monitors, toys, and a bunch of
accessories in the world.
And it's been wonderful seeing
what you've been able to do with
the Core Bluetooth apps that you
build to interface with these
accessories.
Now, this year, as Duy has
mentioned, we're adding support
for Core Bluetooth over BR/EDR
devices or classic devices.
Now these devices range from
things such as car head units,
speakers, and headphones.
So, how do we do this?
Well, our stack from last year
consisted of two different
transports.
Essentially, we were running the
system profiles or things such
as audio, A2DP, HFP, and
remote-control profiles in the
system.
On the other side, for low
energy, we were running Core
Bluetooth over GATT, and that
was the framework that you were
using to interface with your
accessories.
This year, we've merged the two
layers together, and now, you
have transparent access to both
BR/EDR and low energy without
doing anything.
Now, what this means for you is
without much changes in the API,
you can now work with both the
classic devices and the low
energy devices.
So let's go and look into the
details of Core Bluetooth for
BR/EDR.
This now will allow transparent
use of GATT with the BR/EDR
devices.
It's still running the exact
same Bluetooth SIG protocol.
There's no changes to that, and
so you can look at this
specification online on the
Bluetooth SIG website.
To your application and to the
developer, the CBPeripheral APIs
are exactly the same.
You can still do the same
service discovery and be
notified of changes to
characteristics.
There is a new change in the
CBCentralManager.
We've added a way for you to be
notified when a device is
connected with a service IUD or
a known peripheral UID.
And I'll go more into detail
about that later.
Core Bluetooth for BR/EDR is
available with iOS 13, the
watchOS, and tvOS that we
released this week.
And finally, because GATT is a
software layer protocol, you can
add support to your accessory
without the need for new
hardware.
This means only a software or
firmware update.
Now let's look at the new API.
To register for connection events,
you'll register by either a
known service or a known
peripheral UID.
This would be akin to something
like the heart rate service.
You'll call
registerForConnectionEvents, and
you'll pass to the
CBCentralManager a type for
either a service UID or a
peripheral UID.
When we find a matching option,
we'll send you a delegate
callback, and this delegate
callback will include the CB
peripheral and the type of
connection event.
It's pretty simple.
So, what does the incoming
connection look like from your
app's point of view?
Your app will have instantiated
a CBCentralManager, passed us a
known service UID, and in the
case of a BR/EDR or classic
device, your user will go to the
Bluetooth settings and search
for the device, in this case
let's say it's a headset running
heart rate.
They'll discover the device,
find it, and attempt to connect.
Pairing will be triggered, and
then afterwards when we're
connected, we'll run a service
discovery of the GATT services.
If we find a service that you
want, then you'll get the
delegate callback.
And this will now look extremely
similar to those who have
already used Core Bluetooth.
With your delegate callback,
you'll then handle the
connection event, and so you
might call connect on that given
peripheral.
So, all this code looks like so.
You'll do initialization first,
register for your connection
event with the CBCentralManager,
and finally handle the delegate
callback.
If you're interested in the
device, call connect, and then
you can clear the registration
for filters.
Now, what about outgoing
connections.
Let's say you have a known
peripheral already and you're
paired to it and you want to
connect.
You can now connect out to a
BR/EDR device.
To do so, you'll do the same
thing, instantiate your
CBCentralManager and call
connect.
This is not a new API.
This has existed in
CBCentralManager for a while
now.
And so if you're calling connect
on a BR/EDR device, if your app
is in foreground, then we'll try
to make a connection out to that
device for you.
We'll page the device, and if
it's connected, then you'll get
a delegate callback.
It's that simple.
So, now that we've gone through
the new APIs for BR/EDR devices,
let's continue on to the other
improvements we've made for Core
Bluetooth dual-mode.
This means when you're using low
energy and BR/EDR together.
One common thing we've seen with
dual-mode devices, as you've
developed more and more
accessories and apps on top of
it, is that generally when users
use your device, they see two
entries in the Bluetooth
settings.
There's a low energy one, and
there's a BR/EDR or classic one.
And it's sometimes confusing to
users.
So, we worked really hard this
year to alleviate this
confusion.
So, this year we're introducing
adoption of what's called Cross
Transport Key Derivation.
This is a Bluetooth 4.2 SIG
specification, and basically
what this means is through a
single pairing we will derive
link keys for the other
transport.
To you, it means that the device
will now have a single
CBPeripheral identifier, so you
don't need to care about the
transport of the device.
This is completely transparent
to your application, and now
that we have the single pairing
for two devices, it means your
app can seamlessly use both low
energy and BR/EDR together.
So before when users of your
device or application, if they
were seeing two devices, now
they'll just see one, which is
merged.
[ Applause ]
Thank you.
And we can further take
advantage of Cross Transport Key
Derivation, or CTKD, to improve
the pairing process.
So let's say you want to control
the entire discovery and pairing
experience for your user.
Instead of having the user go
into Bluetooth settings and do
an inquiry scan, which leaves
your app experience, you can now
look for low energy
advertisements from your
accessory.
If you find the device, you can
then Call Connect and connect
over LE and access the
protective characteristic.
Once you're paired, because of
CTKD, we'll take the LE key, and
we'll also derive the BR/EDR
key.
And this means you can now make
a BR/EDR connection without
having to trigger more pairing
to confuse the user, and it
stays in the app for the entire
experience.
Great. Now that we've talked
about improving pairing, let's
talk about how we improve
dual-mode connections.
Let's consider a new product
that you want to plan, and it's
a home audio device.
And it would be great if your
user could be using your app and
have it trigger some sort of
connection to use media, such as
music or podcast when the user
becomes in proximity of the
device.
So, you'd want the user to bring
up something like music or
podcasts, which this would mean
that iOS would have to bring up
what's called a BR/EDR channels
for you.
We've done so this year by
introducing a new concept called
bridging.
Bridging works by taking
advantage of low energy
proximity to bring up BR/EDR
profiles such as A2DP, HFP,
AVRCP.
This will work on all devices
that support CTKD and to take
advantage of it in your
application, it's extremely
easy.
You'll use a new key in the
CBManagerConnect, and it's
called the TransportBridgingKey.
You add it in the option
dictionary.
And so when you pass that to us,
we'll try to connect over low
energy to your device.
If we find it, then we'll
immediately page out over BR/EDR
and connect as many profiles as
we can.
The result is that your user can
now seamlessly use all the
multimedia profiles without
having to do anything.
[ Applause ]
Great. So, now we've covered all
the core technology improvements
we've made this year.
I'd like to now hand it over to
Meghna to talk at Core Bluetooth
privacy.
>> Thank you, Yilok.
In the last year alone, there
have been an increasing number
of instances where applications
made the news or we're pulled
from the App Store for not
respecting user privacy.
I'm here today to help you avoid
that situation for your Core
Bluetooth applications.
Hello everyone.
My name is Meghna Lav, and over
the next few minutes, I'd like
to talk you through the privacy
update for Core Bluetooth APIs.
Privacy matters, and it is more
important today than ever
before.
Our users are more aware of it
today than ever before.
At Apple, we believe that
privacy is a fundamental human
right, and as Tim Cook has
mentioned, it is our collective
responsibility to safeguard and
protect the fundamental human
right to privacy.
As developers in the Apple
ecosystem, you all have a
profound impact on user's lives
every day.
As such, users trust you with
their data, and together with
us, you shoulder the
responsibility to uphold that
trust.
This year, we've made
enhancements to two major areas
for Core Bluetooth privacy, user
authorization, and accessory
notifications.
Let's start by talking about
user authorization and how it
currently works.
In iOS 12, if your application
instantiated a
CBPeripheralManager and wanted
to advertise when in the
background, we required that you
obtain user authorization.
New for this year, if your
application uses any Core
Bluetooth APIs, we'll require
you to obtain user
authorization.
It is important to note that
this applies to applications
that are built on older SDKs as
well.
And when a user makes this
decision, they can modify it in
the settings app either in the
Bluetooth privacy pane or even
in your application specific
settings.
And this is required on iOS,
watchOS, and tvOS.
So what does user authorization
mean on watchOS.
If your application runs as an
extension on watchOS, then the
permission is shared between iOS
and watchOS, and the user only
has to grant this permission
once.
This of course is not true for
stand-alone watchOS
applications.
So, how would you adopt user
authorizations in your
application?
The first thing to do is to open
the info.plist of your app and
add this new usage description
string.
There are three reasons why you
should add this usage
description string.
First, you can use this to
convey to users why your
application requires access to
Bluetooth.
Second it is a mandatory string
and failure to adopt it would
lead to a crash upon launch for
your application.
And you see an error like this
in console.
And thirdly, the app review
process reviews all usage
description strings to ensure
that they are nonempty and
meaningful.
So let's take a look at some
code now.
We've created a new property
this year that is the
authorization property, and this
will tell you whether a user has
allowed or denied access to your
application and whether you
check for this authorization
property.
In order to under that, let's
take a look the flow of a Core
Bluetooth application.
In your Core Bluetooth
application, the first thing you
probably do is instantiate a
CBCentralManager or a
CBPeripheralManager.
And so the first delegate
callbacks that you will receive
from Bluetooth will be the
ManagerDidUpdateState callback.
In this, you can look at the
value of state to see if the
manager is ready to be used.
Now if the value of state is
CBManagerstate.unauthorized,
then you can look at a new
authorization property to see if
the user has denied access to
your application.
So if your code looks like this
today, where you only look at
one or two values of manager
state, I urge you to please take
ten minutes aside today and
update your code so it looks a
little more like this where you
look at all the possible values
of manager state, and this also
give you a really smooth path to
start adopting user
authorization in your
application.
All of this code will be
available in the sample project,
details of which will be
provided in the more info
session, section, sorry.
Let's now move onto accessory
notifications.
Apple implements ANCS, or Apple
Notification Center Service,
which is a GATT server service
that allows your accessories to
get system and app notifications
from the iOS Notification
Center.
If you want to learn more about
ANCS, then the detailed
documentation is available on
developer.apple.com.
The privacy update for ANCS is
that user authorization will now
be required in order to share
notifications with accessories.
And so if a user updates to iOS
13, when your accessory connects
in and registers for
notifications, we'll show this
permission prompt to users.
Once users make this decision,
they can modify it under the
device-specific settings in
Bluetooth settings.
Now, we know that this flow
could be a lot better for users
if the permission prompt was
shown at a time when it was more
contextually relevant and in
your application.
And so we've created new ANCS
privacy APIs to help you enable
this experience.
From your CBCentralManager, if
you know that the peripheral
that you are connecting to
supports ANCS, you can use this
new CBConnect option.
If you do this, then upon
successful connection and
pairing, we'll show the
permission alert to the user
while the user is in your
application, and when they
respond to this permission
alert, your application will
receive a delegate callback that
tells you that ANCS
authorization has changed.
And you can fetch the value of
that using the getter
ancsAuthorized.
So, we spoke about user
authorization and accessory
notifications.
But apart from this, there's a
lot more that your application
can do to be a good custodian of
user privacy.
So let's take a look at some
best practices for your Core
Bluetooth applications.
First and foremost, invoke Core
Bluetooth APIs only when
required and at a time that it
is contextually relevant to
users.
Next, scan and advertise for a
limited duration only.
When your application is
advertising, it is essentially
sharing information from the
user's phone and limiting the
duration for which you do this
helps foster user trust.
Keep your scan filters as
specific as possible and look
only for the UUIDs that your
application is invested in.
And lastly, be transparent with
users about why your application
requires access to Core
Bluetooth.
If you do this, then users are
more likely to make the right
decision.
If you want to learn more about
designing your applications for
privacy, I invite you all to
look at the recorded sessions
for the privacy talks from this
year's and previous years' WWDC
sessions.
So let's all be proactive in
thinking about and safeguarding
user privacy as we design and
implement our Core Bluetooth
applications.
I'd now like to hand it over to
Duy to walk you through
developer tools.
Thank you.
[ Applause ]
>> Thanks.
I'd like to talk to you a little
bit about a new feature we've
added to the Core Bluetooth
PacketLogger.
For those that's not familiar
with the Core Bluetooth
PacketLogger, this is our
Bluetooth packet analysis
application built for Apple
developers.
Today, when you install a login
profile on your iOS device and
trigger sys diagnose, this is
the application that can open up
the small PacketLogger file
that's inside.
The application can decode all
protocols defined by the
Bluetooth SIG and by Apple.
And because it can understand
all of these protocols, it will
also highlight errors to warn
you of potential problems.
It has rich filtering options.
You can filter by trust
connections or protocol.
You can search by text or regex,
comment and flag individual
packets, and even export raw
data for later analysis.
This is what the top level looks
like in dark mode, and in this
example, I have filtered only
for the ACI and ATT protocols.
But you can also click down,
click on each of the packets and
drill down to view the full
protocol hierarchy and examine
each of the protocols
individually down to the lowest
layer in raw bytes.
And new for this year, we've
added a feature which we think
you're really going to like.
It's called Live Capture.
[ Applause ]
This means that you can now
install a login profile on your
iOS device, connect it to your
Mac, launch PacketLogger, and
capture live Bluetooth traffic
from your iOS device to an
accessory.
[applause] Thank you.
[ Applause ]
You can also connect multiple
iOS devices and capture live
traffic.
We hope that this will give you
more context when you debug.
It will make your debug more
interactive and hopefully help
you resolve your problems more
quickly.
And now that you're excited, how
do you set up Live Capture?
You can install the iOS 13
developer beta on your iOS
device, install the developer
logging profile, launch
PacketLogger, connect your iOS
device to your Mac, select file
New iOS Trace on your
PacketLogger application, and
that's it.
You're live capturing.
Thank you.
There's also an indicator in
your iOS device to tell that
Live Capture is in progress.
And how do you get PacketLogger?
You can download PacketLogger
inside the additional tools for
Xcode package.
The link will be provided in the
more information page.
PacketLogger is inside the
hardware folder of this package.
For best performance, run with
MacOS Catalina.
Let's wrap up now with a
summary.
When developing your accessory
use the chipset with the latest
Bluetooth stand to take
advantage of all of the new
performance and power
optimizations like LE 2 Mbps and
Advertising Extension.
You can now build Core Bluetooth
apps for Bluetooth BR/EDR
devices.
We look forward to seeing all of
the new applications and
accessories you build.
And always protect your user
privacy and protect their trust
in your brand and product.
And take advantage of the
developer beta.
Download the beta and test
today.
IOS has very good adoption
rates.
You don't want your users to run
into problems when they upgrade.
We usually have a small window
to help.
So if you discover a problem
early enough, you can work with
us to resolve the issues.
And refer to the accessory
design guidelines for Apple
devices.
We have a great set of
guidelines there to tell you how
to develop the best accessory.
And finally, Apple is here to
help.
Use the feedback app, reach out
to us so we can work together in
your accessories and
applications.
And if you have more questions,
come to the Core Bluetooth lab
at 4.
Thank you.
[ Applause ]