The ‘failures’ of the Apple iBeacon(tm) API might not be errors after all: instead, they might hold a hint of a coming generation of wearable devices and, perhaps, the long-rumored iWatch.
We’ve been spending a lot of time on ‘work-arounds’ to how Apple handles Bluetooth LE.
The iBeacon programming framework is deceptively simple: look for some beacons, find them, range them, and then do some stuff now that your phone knows where it is.
But the way that Apple handles seemingly simple tasks can leave you either shaking your head in frustration or creating these little tricks to get your app to do what you want.
We started creating a wish list: either frameworks that we’d like to see developed and shared, or changes to Apple’s API.
But it got us to thinking: what if Apple is doing this on purpose? What if its longer-term intention won’t be to “fix” some of the issues with iBeacon, but to offload those issues onto other devices?
The obvious, speculative answer? An iWatch.
Why iBeacon Doesn’t Work (How You’d Hope It Would)
There are some bugs and glitches with Apple iBeacon and CoreLocation. You need to know about them so that your app doesn’t exhibit strange behavior.
Your app will incorrectly call a didExitRegion, for example, not because there’s something wrong with your beacon but because your phone has these quick, sudden moments when location services is turned off. You’ll be standing right next to a beacon with your phone and your app will suddenly call a “thanks for coming to your store” message, even though you’re standing still.
But for other behaviors, it’s not a glitch, it’s a decision. And while Apple doesn’t document some of the logic, it presents a reason, and the reason is always tied to the user experience.
Your app will delay didExitRegion: They don’t explain the specific algorithm or timing, but Apple does explain that when you exit a beacon region you can expect a delay in your app knowing you’ve left. From a user experience, I guess it makes sense: you want to be absolutely sure that a user has left your store, for example, and so a brief delay while the API validates exit makes sense.
Your app will average out Proximity: Again, they don’t explain their math or algorithm (and you can always use the RSSI and accuracy of your beacon to make your own calculations) but Apple tweaks how your app measures proximity to a beacon because it knows that a) signal interference will change the value over time and b) your phone might be in your hand, your purse or your pocket.
Your app will NOT look for regions if the app has been “hard closed” by the user: Now, others have argued that this isn’t an issue on the premise that most users don’t close their apps (I’ve yet to see hard data to validate this). But if they DO hard close your app all of its features are turned OFF and this includes location services.
So…from a simple, elegant framework you now have both the real world to work with (and figuring out interference levels in different physical environments), the beacons (and figuring out what power levels and UUID/major/minor combos to use) and the obscurity in how Apple describes what’s going on behind the scenes in things like CLProximity.
Your Wish List is an iWatch
But if you had a wish list, what would it be? Apple doesn’t want to drain phone battery, they want to respect their user’s expectations of their phone, and they want to do the best they can with measuring proximity and beacons in the world around you. They want you to be able to turn a phone itself into a beacon but they don’t want to drain battery or have your phone transmitting all the time.
As a developer, you might understand why they do these things, but it doesn’t make your job easier.
Now, imagine what an iWatch could do, and see whether it helps you tick off things on your developer tick list:
It would always look for location and beacons. Instead of every app doing location calls, it would be a single source for location and beacon ranging which would be provided as a single service to multiple apps.
It would have greater accuracy of location because it would rarely be in a purse or pocket
It would always be a beacon, on the same premise that it could act as a single ‘service’ to multiple apps
Because it would both be a beacon and receive beacon data, it would have greater precision – by sharing information back-and-forth with other beacons, it could more accurately determine its position. If a Bluetooth LE beacon could also receive other beacon data, the two data points can make a much more accurate determination of proximity.
Because you’d never turn it off, and because it’s infinitely more accessible than a phone, the user would have greater and more granular control over their ‘beaconized’ experiences, and therefore user agency and trust could be increased because the action of opting in/out would be easier
With its own battery, you can now distribute power requirements over two devices, letting each one carry a different part of the battery ‘burden’
So maybe the challenges and problems with iBeacon are partly intentional. Rather than letting an ecosystem of apps develop that treat your phone as the endgame in proximity accuracy, location services and user experience Apple is putting ‘throttles’ in place in the knowledge that these challenges will be solved by moving their solution not to the phone – but to a new line of connected devices.
Or maybe, like my dreams of the perfect app based on the perfect Bluetooth LE API, it’s just wishful thinking?
Join Our Mailing List: Once-a-Week
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!