What exactly can CoreBluetooth applications do whilst in the background?

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

Leave a Comment