What's New in Core Bluetooth

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.

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. Thank you. 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 , 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. 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. 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.

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. 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. 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. Thank you. 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 ]