0
votes

I would like to use CoreBluetooth to detect the proximity to a hardware (emitting BLE signals) when the app runs in background.

The first step is activating BLE background mode in the capabilities tab. This will allow the app to receive BLE signals also when running in background. Now, the second step would be to write the code to detect the proximity to the BLE peripheral.

Looking at the iOS developer Bluetooth guide (at page 45/46) I found:

CBCentralManagerScanOptionAllowDuplicatesKey constant as a scan option when calling the scanForPeripheralsWithServices:options: method. When you do, a discovery event is generated each time the central receives an advertising packet from the peripheral. Turning off the default behavior can be useful for certain use cases, such as initiating a connection to a peripheral based on the peripheral’s proximity (using the peripheral received signal strength indicator (RSSI) value). T

  • Is this the correct direction for this?
  • In terms of iOS device battery usage, is this approach less efficient than using iBeacon?
1

1 Answers

2
votes

Yes, it is a valid approach to use CoreBluetooth as you describe. You can get a callback for each packet you detect in the foreground (and in the background for non-manufacturer advertisements). You can then read the RSSI as an indicator of proximity.

Whether you want to use CoreBluetooth or use iBeacons with CoreLocation, the battery usage is similar in most foreground ranging cases.

If using CoreBluetooth, you probably don't want to keep getting callbacks for every packet indefinitely in the background, because it would drain the battery faster. CoreLocation iBeacon APIs limit you to 10 seconds of ranging in the background for each wakeup event to help save battery.

If you see your app ranging for longer periods in the background using CoreBluetooth you may want to add your own logic to protect against battery drain.