Bluetooth Low Energy (BLE) has been available since the iPhone 4S and iPod 5th Gen. BLE is a subset of the Bluetooth specification part 4.0. It’s not a quick read. On iOS devices, BLE is programmed via the CoreBluetooth module which is pretty expansive too. Coupled with that, the latest radio sub-systems multiplex the antenna between BLE and WiFi.

On top of all this, a BLE app is generally going to be communicating with some custom bespoke hardware. Probably based on a reference kit such as the nRF5 from Nordic Semiconductors .

Added together, these layers of complexity can and often do make for a challenging development environment (and we haven’t mentioned Apple Notification Centre Service yet either, and we’re not going to in this post).

Generally your app will be executing in the foreground while in use, so will have reliable access to all iOS device resources.

However, a large subset of BLE applications involve tracking and locating things. Think Tile, HipKey and many more (especially on Kickstarter). These often need to continue detecting BLE devices when the user has put the app into the background.

Apple has a fair bit to say about what can and cannot happen in the background with BLE.

In the section “The bluetooth-central Background Execution Mode”:
  • “and multiple discoveries of an advertising peripheral are coalesced into a single discovery event
  • “ …. it may take longer to discover an advertising peripheral.”
  • “These changes help minimize radio usage and improve the battery life on your iOS device.”
Also in the 3rd paragraph:
  • “Even if your app supports one or both of the Core Bluetooth background execution modes, it can’t run forever. At some point, the system may need to terminate your app to free up memory for the current foreground app”
So from this we learn several things, firstly that it will only log one sighting of a device (the first) and that it won’t detect things as quickly and it may be put into hibernation where it can’t see / do anything at all. We also see the reasoning behind these restrictions, namely preservation of battery charge.
Over the last 5 years we have built up a number of iOS app tools to investigate how these behaviours are modified between iOS versions. We have even submitted some bug reports based on findings.
We also monitor the various threads on Apple’s developer forums and Stackoverflow. The picture continues to evolve, but in the light of the on-going evolution of BLE on the iOS and OSX platforms, one wonders if Apple has another technology up its sleeve.
Update: We’ve been updating our Android BLE background modes knowledge over the summer, first indications are it’s now a lot less restrictive than iOS. A topic for a future post.