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)
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?
Be the Beacon!