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.
- “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.”
- “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”