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.


  • 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...
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!

13 thoughts on “Apple iBeacon Bugs Complicate Bluetooth LE Experience

  1. Region Monitoring

    “region events may not happen immediately after a region boundary is crossed. To prevent spurious notifications, iOS does not deliver region notifications until certain threshold conditions are met. Specifically, the user’s location must cross the region boundary and move away from that boundary by a minimum distance and remain at that minimum distance for at least 20 seconds before the notifications are reported.”


  2. Yes – that’s true Guenther – as I say, it’s not a mistake that it takes time to ‘exit’. It’s a good thing that there’s a delay.

    HOWEVER, there’s also a bug where you WILL exit, even though your phone is in exactly the same place and nothing has changed. Location services seems to turn off for a brief millisecond, enough to call a false region exit.

    You can see it in the error logs.

    Three observations:

    – It takes time for region boundary conditions to be met
    – The 20 second rule isn’t a true number – it can vary from 5 seconds to 30 in our tests
    – Your phone will sometimes turn location services off for no reason which will force an “exitregion” call and have your app start scanning for regions again.


  3. The problem I seem to be getting most of the time is a display of immediate proximity when I am clearly out of range of the iBeacon. I can be well over 40 or 50 feet away from the device and it will still display an “immediate” proximity. By walking close to the device it will eventually correct itself from immediate back to near and then immediate again (when it is actually within immediate proximity). So frustrating! Anyone else have this issue?


  4. Yes, we get exactly the same behavior. Right now, we consider the Apple API to be ‘broken’ in this regard. As a result, we tend to be using signal strength to calculate proximity rather than ranging and then setting a timer or counter for number of times you poll within a range of signal strengths.

    We get the same behavior you do, and also get ranging turning off entirely for brief intervals (it basically loses the signal and then needs to start over…it last for less than half a second but enough to throw you off!)


  5. Observing the same behavior here while playing with Estimote beacons.
    How do you calculate “proximity” out of signal strength?


  6. Hi,

    We are experiencing the same kind of “troubles” with our BLE iBeacon here. Air traces clearly shows that our chip is correclty transmitting advertising events with a period of 30ms and as we are even facing similar issues between 2 iOS devices, we consider this for now as an Apple “Work In Progress API” issue. From what I see in the API reference, the beacon region misses a reliable Timeout Interval property.


  7. Changing the time of the signal to 100ms gives a far more stable proximity change. Change the time to a large value such as 900ms and you will see the proximity go a little wild and it takes some time to stabilise, then set this to 100ms and you will see that a decision is made very quickly as to the proximity status.


  8. Hi,

    We have tested several iBeacons with several setups for region monitoring (Ranging beacons). Range entrance detection time is quite satisfactory, it almost never misses a region, plus it immediately (within a second) detects entering a region even the iOS application is suspended.
    However, there are ideas that iBeacon region detection times in background could be as far as 30 seconds. I have never met such a situation but even big iBeacon producers such as Radius Networks have blog notes about that.

    I have been testing ranging beacons for the last three months and never met a situation that detection is more than 3 seconds. Are those ideas “Entrance detection times could be as long as 30 seconds” were based on older iOS API? Is there anyone who tried and suffer about region entrance detection times?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s