Kinvey, a powerful backend as service provider for mobile developers, agencies and enterprise, recently launched iBeacon and BLE support.
As a companion to its launch (and demo at the Gluecon conference), Kinvey developer Mike Katz has written an exceptional overview of their experiences developing a beacon-enabled app.
The launch of iBeacon/BLE support by Kinvey validated what I call the rush to the middle. It’s the tendency in new markets for innovation to come from two directions:
- From the ‘bottom of the stack’ (in this case the device itself). The chip makers start making their own beacons (see Texas Instruments), the beacon makers start making cloud-based services (see Kontakt for a company that’s slowly, but surely, building a richer suite of cloud-based tools)
- The larger players start extending existing tools and cloud-based systems with beacons, working their way ‘down the stack’
Kinvey, perhaps, sits somewhere in the middle. (At the top of the heap are the big players like Facebook and Pinterest – one of whom will be first to bring beacons to a massive consumer platform).
Now, they won’t want me to say this, but Kinvey is the enterprise-grade Parse. While Parse focuses on the widest possible developer community and has incredibly rich, robust tools, they still feel like a platform for Facebook-style games and narrowly-focused apps.
Kinvey, on the other hand, is their enterprise-grade companion.
This expertise is seen in the post by Mike Katz, who takes an in-depth tour of the considerations and challenges in developing a beacon-enabled app. His post is particularly brilliant because of the emphasis it places on user signals, education, and permissions.
Amongst his conclusions:
- Not all beacons are iBeacons. iBeacons are better. Beacons broadcast (generally Bluetooth) unique identifier numbers. Apple provides support for iBeacons by recognizing them and knowing their range. Apple will continue to monitor for beacons if an app is not running.
- Make your feature compelling enough to get the user to turn on their bluetooth and location. You get one chance to ask for permission, choose wisely.
- iBeacon monitoring is actually quite battery efficient, but the tech media has been telling people otherwise. Make sure your app clearly indicates the battery efficiency and encourages them to leave bluetooth on.
He even offers a handy chart of features and their restrictions, reminding us about what user permissions and ‘toggles’ need to on for iBeacon monitoring to work:
One comment in Mike’s post left me slightly mystified. I’ll be following up with him in the coming days for clarification and for other insights.
In his post, he says:
When choosing features, it’s important to keep in mind that when the app is in the background, even if it’s killed, the device still monitors for the presence of beacons (this is known as region monitoring). Only iBeacons can be monitored in this way; if you use another type of Bluetooth beacon, the app needs to be active to search for them.
What mystifies me here is the exact definition he’s using for “iBeacon” – and how the app knows that one BLE beacon is an iBeacon while another isn’t.
Regardless, the post provides excellent insight into the challenges, user considerations, and permissions needed for an iBeacon-enabled app to work and is worth a read for even the most experienced developer.
For further reading, Kinvey has provided a series of posts following its launch of iBeacon support. Check them out:
The Coming Beacon App Revolution: 4 Phases of Business Enablement via Smartphones and Tablets
Beacon Applications in Retail and at Events (Part 1): Think Personalized Experiences and Increased Revenue
Beacon Applications in the Home and Office (Part 2): Think Operational Efficiencies and Cost Savings
Share Your Thoughts
Have you used the Kinvey iBeacon SDK? Who will be the next “platform” to extend into iBeacon support? And what, exactly, is the difference between the ability for your iPhone to monitor for “iBeacons” vs, um, “regular beacons”?