What exactly can CoreBluetooth applications do whilst in the background?

Question

The subject says it all, really. Documentation, insofar as it exists at all, suggests that apps written against the CoreBluetooth framework running on iOS devices can add "bluetooth-central" to their background privilege list and so process some kind of Bluetooth events whilst inactive, but which exact events do and do not get delivered?

For example:

1. Can I carry on communications with a device I already established a pairing with?
2. Can I issue periodic discovery requests to find devices which are out of range / I've never seen before? (For example if I wanted to be able to deliver a notification when a new interesting device is encountered)
3. What if a device goes out of range and then comes back? Will I get disconnected and connected events without user intervention, or will I need to be foregrounded and have the user explicitly request reconnection?

Answer 1

Nobody seemed to know, so I bought an iOS developer account and ran some experiments. Here's what I found:

When running in the foreground, you can start a scan using CBCentralManager::scanForPeripheralsWithServices. Your scan can be restricted to devices advertising a particular service, or unrestricted (pass nil for that call's parameter). It can also allow or disallow duplicates; in the former case you'll get a didDiscoverPeripheral callback every time the iPhone receives an advertisment packets; in the latter you'll only get one callback per device found.

When you enter the background, the rules appear to be as follows:

• If you were running an unrestricted scan, it will be silently cancelled. You will not get any didDiscover callbacks.
• If your scan was restricted (i.e. you specified one or more service UUIDs you were looking for), your scan will continue to run, but the allow duplicates flag will be ignored. This means that you will now only get didDiscoverPeripheral callbacks for new devices. If all devices were seen whilst in the foreground you will get no callbacks at all.
• Starting and stopping the scan does not reset which devices are considered new. If there is one device present, you will only get a single callback, even across multiple scans, unless...
• If you connect to a device, then disconnect, then scan again, the device will be enumerated again (i.e. you will get one more call to didDiscoverPeripheral). I guess iOS regards that as having "shown interest" in the device.

I don't know whether connect attempts to nonconnectable devices (e.g. BLE Advertisers, like those implementing the proximity profile) is good enough as my example devices are connectable. However at least for connectable devices, this scan/connect/disconnect/scan procedure suffices to poll for a device's presence in the background.

The above results were gathered using an iPhone 4S running iOS 5.0.1

Answer 2

In addition to Chris's answer:

• If your app has "bluetooth-central" background mode and is connected to a peripheral, you can receive notifications (peripheral:didUpdateValueForCharacteristic:error:) from the peripheral in background, even after 10minutes.

So when you want to continuously run in background you have 2 options:

• Run the "connect, disconnect, scan again" loop
• Make the peripheral send notifications

Later should be the "Event backgrounding" from WWDC 2012 Core Bluetooth videos https://developer.apple.com/videos/wwdc/2012/ But the former looks like a hack, I don't want to rely on it.

I tested this on iPhone5, iOS6.1.4

---

Apple finally released the Core Bluetooth Programming Guide and here's the official note about

Core Bluetooth Background Processing for iOS Apps