UX Guide to Core Bluetooth

An overview of Core Bluetooth and how you can create UX experience with external devices powered by BLE such as medical monitoring devices.

Core Bluetooth was Brough to market in late 2010 and is intended to work with both macOS and iOS (Core Bluetooth background execution modes aren’t supported in iPad apps running on macOS) and later on it was expanded to tvOS in 2016. In 2017 it was further expanded to support WatchOS 2 and works on app Apple Watches Series 2 and above.

What’s Core Bluetooth? As mentioned above it is a iOS framework provided by Apple framework for communicating with devices that support Bluetooth 4.0 low-energy, often abbreviated as BLE. And it opened up standard communication protocols to read and/or write from external devices.

The Core Bluetooth framework provides the classes needed for your apps to communicate with Bluetooth-equipped low energy (LE) and Basic Rate / Enhanced Data Rate (BR/EDR) wireless technology.

What is Core Bluetooth?

A Generic Attributes (GATT) profile describes how to bundle, present and transfer data using Bluetooth Low Energy. It describes a use case, roles and general behaviours. A device’s GATT database can describe a hierarchy of services, characteristics and attributes.

The classic server/client roles are the central app and the peripheral or accessory. In the starter app, either iOS device can be central or peripheral. When you build the Watch app, it can only be the central device.

The most interesting classes in the Core Bluetooth framework are CBCentralManagerand CBPeripheralManager. Each has methods and a comprehensive delegate protocol, to monitor activity between central and peripheral devices. There’s also a peripheral delegate protocol.

Core Bluetooth has several key features of note:

The ability to set up an iOS device as Bluetooth Low Energy as central or peripheral device.
Handling low-level connection settings.
Primary method of transferring data between BLE devices, such as phone to device or watch to device.
Error handling management.

Opportunities to shape the experience.

Central devices need to scan for and connect to peripherals. Peripherals need to advertise their services. A central manager’s main jobs are:

1. If Bluetooth LE is available and turned on, the central manager scans for peripherals. This experience can be within your app or controlled by iOS and then detected by your app.

2. If a peripheral’s signal is in range, it connects to the peripheral. It also discovers services and characteristics, which it may display to the user to select from, subscribes to characteristics, or requests to read or write a characteristic’s value.
Once connected, the central device needs to discover the peripheral’s services and characteristics, using peripheral delegate methods. Often at this point, an app might present a list of these for the user to select from.

A peripheral manager’s main jobs are to manage and advertise the services in the GATT database of the peripheral device. You would implement this for an Apple device acting as a peripheral. Non-Apple accessories have their own manager APIs. Most of the sample BLE apps you can find online use non-Apple accessories like Arduino.

If Bluetooth LE is available and turned on, the peripheral manager sets up characteristics and services. And it can respond when a central device subscribes to a characteristic, requests to read or write a characteristic value, or unsubscribes from a characteristic.
If the central app is interested in a characteristic, it can subscribe to notifications of updates to the characteristic’s value, or send a read/write request to the peripheral. The peripheral then responds by sending data to the central device, or doing something with the write request’s value. The central app receives updated data from another peripheral delegate method, and usually uses this to update its UI.

Methods in this protocol indicate availability of the central manager, and monitor discovering and connecting to peripherals. Follow along in the CBCentralManagerDelegate extension of CentralViewController.swift, as you work through this list:
Eventually, the central device might disable a notification, triggering delegate methods of the peripheral and the peripheral manager. Or the central device disconnects the peripheral, which triggers a central manager delegate method, usually used to clean up.

Methods in this protocol indicate availability of the peripheral manager, verify advertising, and monitor read, write and subcription requests from central devices. Follow along in the CBPeripheralManagerDelegate extension of PeripheralViewController.swift, as you work through this list:

watchOS vs iOS

iOS apps can be central or peripheral, and can continue using CoreBluetooth in the background. Meaning that since 2017 the experience has been defined by external devices and Phones but you can now define an experience with a Watch and an external device.

Both WatchOS and tvOS both rely on Bluetooth as their main system input, so Core Bluetooth has restrictions, to ensure system activities can run. Both can be only the central device, and can use at most two peripherals at a time. Peripherals are disconnected when the app is suspended.And the minimum interval between connections is 30ms, instead of 15ms for iOS and macOS.

Design & Prototype connected experiences

With this background in understanding what Core Bluetooth is and how it works. We can start to explore what an app would need to display to the user to connect to a Bluetooth enabled device. Also what experiences are possible further along, in daily continues experiences.

More to follow.