Bluetooth Beacon Discovery and Ranging: How Long Does an iOS App Take to Find a Beacon?

How long does it take your iBeacon app to discover it’s in range of a Bluetooth beacon? How long does it take for a lock screen notification to reach your user?

These aren’t trivial questions. But finding the answers isn’t a trivial exercise either. And the main reason seems to be that Apple isn’t transparent about its strategies for battery conservation and prioritization of app background tasks. Add this to the variation in signal strength from different Bluetooth LE devices and the answers get complicated.

Is it the phone itself which is conserving battery power by lowering the number of times it ‘searches’ for beacons? Or is it the variability in the beacon signal strength? So far, it seems like it’s a bit of both.

The key to this answer? You might not love the variability it places on your app – but your user will love that their phone never runs out of juice.

The Challenge of Getting Answers
We’ve been trying to nail down some specific and reliable metrics but we’re challenged by a few things: first, we now have an office full of beacons. They seem to be perched in every corner, and we have both virtual beacons and physical beacons running. With no “off” switch, we practically need to put beacons into storage to have ‘clean’ tests with a single set of beacons.

Second is the issue of space itself: we get different results in different venues. The main factor in the space is interference – metal in the walls, shelving, whether the space is open or has enclosures.

Finally the devices: it’s hard to nail down comparisons for different iPhone and iPad models unless you have the whole line.

Range Times and Notifications
With the above in mind, this is anecdotal information only and it might not be that informative but we thought we’d share. Namely:

  • That the time it takes for your app to discover it’s within range of a Bluetooth beacon can vary from a second or two up to 15 seconds;
  • The time it takes for discovery of a beacon and the ‘pushing’ of a lock screen message can, in rare cases, take minutes; and
  • Tracking the user’s movement between regions can be reasonably fast if the user’s app is open (i.e. instantaneous).

Does that mean that iBeacon is unreliable? Well…yes and no. The answer depends on the context in which you put it: both the use case (you need to send a lock screen message prompting the user to open the app at the very instant someone arrives at your ticket booth, say) and the larger user experience on the phone or tablet.

Put it this way: if you wanted to be extremely responsive and extremely fast, most of our collective users will end up turning Bluetooth OFF because their batteries would quickly drain. Happy users might be a win for the industry in general, but might NOT solve your immediate challenge of responsiveness when coming into range of a beacon.

Apple makes a lot of decisions behind the scenes about how to prioritize background updates, location, M7 microprocessor tasks, and other features of the phone in general. Its goals are to make the user experience smooth and reliable while conserving battery strength as much as possible and not putting an undue burden on bandwidth (doing app updates in the background, for example, mainly when there is a reliable WiFi connection).

As a result of these background decisions (whose logic we can’t clearly know) it seems to us that the responsiveness of your app to discovering nearby beacons is (to use an ugly term) throttled by factors as variable as:

  • The number of apps running background tasks
  • The amount of bandwidth your device is using for other tasks
  • How many apps you already have open
  • How recently you opened your app
  • Whether its open (which gives the ultimate responsiveness)

Looking Ahead
This might sound daunting. Scary even. But what it really points to is a simple fact: deploying iBeacon technology, while seemingly ‘trivial’, is NOT.

Just like you can’t pop a beacon on the wall and expect to create a user experience without a robust back-end, you’re going to need to look at a fully integrated solution of beacons, geofencing, push notifications of different types, beacon triangulation, beacon signal strength and other factors to create a user experience that feels to the user like it’s elegant and useful.

Put it this way: a user walks into your restaurant and heads to the restroom. That might not be the place you want to send them a lock-screen “Welcome, Enjoy Your Stay” message. You’ll need to be smart about your push messages based on your use case and the range of response times, or supplement beacons with geofencing, tweaks to the beacons and intelligent use of the iBeacon API.

Now, the above is anecdotal at this stage: but what have your experiences been? Have you been able to narrow down a range of response times? And what factors seem to play a role in how fast an app will ‘wake up’ to notifications and range changes?

Jump Onto Our Mailing List
Why not join our mailing list for ‘BEEKn unplugged’?
And check out our flashy awesome company site too.

Be the Beacon!

4 Responses to “Bluetooth Beacon Discovery and Ranging: How Long Does an iOS App Take to Find a Beacon?”

  1. Great article. With your experience having all of these beacons laying around, are you seeing better performance out of one manufacture over another?

    Reply
  2. Thanks John. And wow…tricky question. The simple answer is no. A signal is pretty much a signal. There’s no real variation in the data or anything since it’s a standard packet. The range is pretty much the same across devices if they’re all set to the same signal strength. But where it gets tricky is the SDKs each of the beacons come with, what kind of battery the beacons are powered by, how long the battery is projected to last at different signal strengths and whether you have the capacity to adjust the beacon settings.

    You don’t NEED to use an SDK but I imagine a lot of people WILL. How the SDK handles graceful zone exits and things like that play a big part in the impression you have of the beacon. And if you choose a beacon with the intent of using the supplier’s back-end then you’ll want to pay a lot of attention to the software on the “cloud” and app side.

    So here’s where you end up: if you want to tinker with the beacon’s settings and don’t mind really digging in with your own work on the app-side code, I’d say the difference between the beacons as ‘beacons’ is negligible (not to say there isn’t a difference – there is, but it’s less in the performance of the ‘beacon’ as a bluetooth signal and more on all the other features like battery, accelerometers, durability, form factor etc).

    We’ve got a few more beacons coming our way – I’ll write up some general comparisons in a future post on the wider decision about choosing a beacon supplier for, you know, an actual job. :)

    (If you want to do a much of prototypes and just hack around for now, just grab a bluetooth dongle for your laptop or turn your Mac into a beacon…or maybe grab a few GeLo’s. If you want to show off and get a lot of oohs and ahhs get a set of Estimotes because they look real cute, but be prepared to do a bit of hacking around with the code).

    Sorry I’m not more definitive but does that help?

    Reply
  3. We’ve had some good offline chats about this topic. Apple specifically notes that for *region* monitoring, there can be a 10 second delay in relaunching a suspended app, and in the case of beacon detection there are several factors.

    One of those factors is resolving multiple devices. This actually didn’t occur to us when testing Estimote and we may be getting “lag” of response because our devices are detecting 3 Estimotes:

    “The proximity property based on the original Bluetooth identifier reports a value of CLProximityUnknown within 2 seconds of the identifier change. Within 10 seconds, the identifiers resolve and only one beacon region is reported”

    The other variable is the frequency with which the app polls in different scenarios.

    https://github.com/Estimote/iOS-SDK/issues/18

    Use region monitoring to wake the app and beacon monitoring once the app is open.

    Reply

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>