Apple iBeacon Bugs Complicate Bluetooth LE Experience

Before you attack your new Bluetooth LE beacon in frustration you can blame a possible bug in the Apple API for sudden state changes in finding and ranging beacons.

After banging our own heads, Dan Nolan from Proxima confirmed a problem we’d been seeing and which we initially blamed either on the beacons themselves or interference of some kind.

Namely:

• Your app is likely to lose range of beacons for brief instances and will briefly report didExitRegion before quickly returning to being in range
• Your app will sometimes make the wrong ‘guess’ as to which proximity region it’s in before eventually correcting itself. It will sometimes report Proximity == near when you’re “immediate” or “immediate” when you’re “near” and then flip itself back to the correct value.

The bug is hard to nail down because Apple hasn’t documented the logic behind how it’s API works and doesn’t tell us how, exactly, they calculate proximity (which is a kind of rolling average and calculation based on signal strength and the accuracy packet). There are two key steps that your app will take in “finding” beacons:

Ranging Beacons
Using didStartMonitoringForRegion your app will ‘look’ for beacons while open or in the background tray. Once it finds them, you can initiate an action with didEnterRegion.

This one is simple enough and while the response time varies depending on whether your app is in the background or foreground and, weirdly, how long your app has been open or whether you’ve recently ranged, it works well enough.

It’s how the app monitors leaving a region that makes things complicated. With didExitRegion the API is ‘smart’ enough to delay itself when you leave a region to make absolutely sure you’re gone. Usually, this delay seems to be 3-4 seconds, whereas it will detect a proximity change in 1 second or under.

Phone and beacon stay in a fixed position and then this happens…

However, the bug we’ve run into is that your app will sometimes say that you’ve left a region and then immediately correct itself. This might be due to signal interference. Using HiBeacon or other beacon monitoring apps, we’ll see brief “cutouts” in power displayed – but our suspicion is that there isn’t an actual cut-out, it’s the detection that’s the issue.

What’s strange about the bug is that under ‘normal’ conditions, the app won’t report didExitRegion until it’s confirmed that you’ve actually left. But in the issue of the bug, no confirmation happens – it just “exits” itself from the beacon region and then immediately flips back.

Beacon Proximity
As noted above, your app will sometimes make the wrong guess as to which region it’s in. Using CLProximity, the API seems to have been set up to correct itself as more data comes in. Your app may be right next to a beacon and it will ‘guess’ that it’s near, but then correct to immediate. But these corrections aren’t predictable. And when the app is guessing “immediate” but you’re actually “near”, you can have weird decisions to make about the user experience.

One time you put your app next to a beacon and it pushes a coupon, the next time it pushes an ad for shoes. Not at least being able to predict what factors will help the app get it ‘right’ is frustrating to say the least…and it’s either an out-and-out bug or a flaw in the logic behind the scenes.

What to Do?
The work-arounds to these issues all feel like hacks. Instead of the Apple API gracefully moving between finding and leaving regions and coming into proximity of beacons, you need to insert additional logic to avoid rapid ‘toggling’ and to ‘fix’ the last beacon reading in the case of a brief didExitRegion call. Dan and Apple itself have suggested that CLProximity won’t be the API you want to use if you’re really putting beacons through their paces: and you’ll need to calculate proximity based on RSSI and accuracy from the beacon advertising packet.

We’ve tested this on three different types of beacons, so it doesn’t seem to be related to the manufacturer of the beacons.

But have you seen similar results to those above? Are they “bugs” or just the reality of beacons which needs to be corrected for with code? Let us know in the comments below or drop me an e-mail.

Jump Onto Our Mailing List

Let’s chat on Twitter! We have some good conversations. Or join our weekly mailing list for ‘BEEKn unplugged’ – I rant a little each Friday and share stuff that doesn’t make it on the site.

Be the Beacon!