We started today playing with Eddystone. Updated one of our beacons and set it to broadcast Eddystone UUID, so we can see the behaviour.
For Eddystone there is only 1 callback to delegate to discover Eddystone beacons - didDiscoverEddystones. This works fine on the foreground, but when we tested it on the background it stopped. We then concluded that Eddystone is using CoreBluetooth only, compared to iBeacons that use CoreBluetooth and CoreLocation for monitoring or scanning on the background.
So, we took the official Google Eddystone sample project for iOS and ran it on the background and we saw that it was detecting Eddystone beacons. The reason that was still detecting was that they enable the Background flag “Uses Bluetooth LE accessories”, which made the Eddystone scanner still running on the background, but we don’t know if Apple will approve this.
We are having a location based app called Situate and we are using on the background and app killed mode the iBeacons to monitor and scan for nearby beacons.
Our question is if you are going to add any extra methods/callbacks for Eddystone or if there are any available methods/callbacks which are similar to iBeacons where you can monitor or scan on background or even wake up the app when the app is killed?
Yeah, the story with background scanning of Eddystone on iOS is slightly complicated.
With iBeacon, you get this out of the box because iBeacon devices are being detected via Core Location. All you need to do is request the “always” authorization to access Location Services.
Eddystone to iOS is just another BLE, non-iBeacon device, so it’s handled by Core Bluetooth. CB does allow detecting devices in the background, you just need to enable Background Modes support in your app—specifically the “uses BLE accessories” one, as you noticed. You’ll likely need to mention to the review team why and how your app utilizes this privilege. If you do that, there shouldn’t be any problems getting approval.
More importantly however, CB in the background has certain limitations. This is what Apple’s documentation says:
Although you can perform many Bluetooth-related tasks while your app is in the background, keep in mind that scanning for peripherals while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is scanning for device while in the background:
The CBCentralManagerScanOptionAllowDuplicatesKey scan option key is ignored, and multiple discoveries of an advertising peripheral are coalesced into a single discovery event.
If all apps that are scanning for peripherals are in the background, the interval at which your central device scans for advertising packets increases. As a result, it may take longer to discover an advertising peripheral.
These changes help minimize radio usage and improve the battery life on your iOS device.
We’re still investigating how exactly CB works when the app is not running and if there’s a way to have the app relaunched on a Bluetooth event, just like with iBeacon. Once we’re better informed, we’ll be adding background Eddystone scanning to the SDK, so stay tuned (:
Sadly, no news at this time. It’s not a trivial problem to solve—note, e.g., that Google’s Nearby API for iOS also doesn’t support background scanning.