All Bluetooth-related events that occur while a foreground-only app is in the suspended state are queued by the system and delivered to the app only when it resumes to the foreground. That said, Core Bluetooth provides a way to alert the user when certain central role events occur. The user can then use these alerts to decide whether a particular event warrants bringing the app back to the foreground.
There are two Core Bluetooth background execution modes that an app may declare—one for apps implementing the central role, and another for apps implementing the peripheral role. If your app implements both roles, it may declare that it supports both background execution modes. The Core Bluetooth background execution modes are declared by adding the
UIBackgroundModeskey to your
Info.plistfile and setting the key’s value to an array containing one of the following strings:
bluetooth-central—The app communicates with Bluetooth low energy peripherals using the Core Bluetooth framework.
bluetooth-peripheral—The app shares data using the Core Bluetooth framework.
When an app that implements the central role includes the
UIBackgroundModeskey with the
bluetooth-centralvalue in its
Info.plistfile, the Core Bluetooth framework allows your app to run in the background to perform certain Bluetooth-related tasks. While your app is in the background you can still discover and connect to peripherals, and explore and interact with peripheral data. In addition, the system wakes up your app when any of the
CBPeripheralDelegatedelegate methods are invoked, allowing your app to handle important central role events, such as when a connection is established or torn down, when a peripheral sends updated characteristic values, and when a central manager’s state changes.
Although you can perform many Bluetooth-related tasks while your app is in the background, keep in mind that scanning for peripherals while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is scanning for device while in the background:
CBCentralManagerScanOptionAllowDuplicatesKeyscan option key is ignored, and multiple discoveries of an advertising peripheral are coalesced into a single discovery event.
- If all apps that are scanning for peripherals are in the background, the interval at which your central device scans for advertising packets increases. As a result, it may take longer to discover an advertising peripheral.
These changes help minimize radio usage and improve the battery life on your iOS device.
To perform certain peripheral role tasks while in the background, you must include the
UIBackgroundModeskey with the
bluetooth-peripheralvalue in your app’s
Info.plistfile. When this key-value pair is included in the app’s
Info.plistfile, the system wakes up your app to process read, write, and subscription events.
In addition to allowing your app to be woken up to handle read, write, and subscription requests from connected centrals, the Core Bluetooth framework allows your app to advertise while in the background state. That said, you should be aware that advertising while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is advertising while in the background:
CBAdvertisementDataLocalNameKeyadvertisement key is ignored, and the local name of peripheral is not advertised.
- All service UUIDs contained in the value of the
CBAdvertisementDataServiceUUIDsKeyadvertisement key are placed in a special “overflow” area; they can be discovered only by an iOS device that is explicitly scanning for them.
- If all apps that are advertising are in the background, the frequency at which your peripheral device sends advertising packets may decrease.
Any app that declares support for either of the Core Bluetooth background executions modes must follow a few basic guidelines:
- Apps should be session based and provide an interface that allows the user to decide when to start and stop the delivery of Bluetooth-related events.
- Upon being woken up, an app has around 10 seconds to complete a task. Ideally, it should complete the task as fast as possible and allow itself to be suspended again. Apps that spend too much time executing in the background can be throttled back by the system or killed.
- Apps should not use being woken up as an opportunity to perform extraneous tasks that are unrelated to why the app was woken up by the system.
Because state preservation and restoration is built in to Core Bluetooth, your app can opt in to this feature to ask the system to preserve the state of your app’s central and peripheral managers and to continue performing certain Bluetooth-related tasks on their behalf, even when your app is no longer running. When one of these tasks completes, the system relaunches your app into the background and gives your app the opportunity to restore its state and to handle the event appropriately. In the case of the home security app described above, the system would monitor the connection request, and re-relaunch the app to handle the
centralManager:didConnectPeripheral:delegate callback when the user returned home and the connection request completed.
Core Bluetooth supports state preservation and restoration for apps that implement the central role, peripheral role, or both. When your app implements the central role and adds support for state preservation and restoration, the system saves the state of your central manager object when the system is about to terminate your app to free up memory (if your app has multiple central managers, you can choose which ones you want the system to keep track of). In particular, for a given
CBCentralManagerobject, the system keeps track of:
- The services the central manager was scanning for (and any scan options specified when the scan started)
- The peripherals the central manager was trying to connect to or had already connected to
- The characteristics the central manager was subscribed to
Apps that implement the peripheral role can likewise take advantage of state preservation and restoration. For
CBPeripheralManagerobjects, the system keeps track of:
- The data the peripheral manager was advertising
- The services and characteristics the peripheral manager published to the device’s database
- The centrals that were subscribed to your characteristics’ values