How proximity approaches compare and a look at the flourishing proximity startup ecosystem.
In the first of this series, I covered some of the basics behind proximity, Bluetooth Low Energy, and iBeacon, and walked through some use cases where proximity and iBeacon have started showing up in retail, travel, and other applications.
While iBeacon has arguably galvanised the notion of using proximity in applications and services, it’s not the only game in town.
In this post, I’ll cover one of the alternatives to Apple’s iBeacon, Physical Web from Google, and then I’ll zoom out to look at the flurry of activity in startups in the evolving “Beacosystem.”
First, a small recap on what helped iBeacon gain so much traction, so quickly and helped shape the landscape for a proximity ecosystem to emerge.
Creating an ecosystem
Apple’s iBeacon is a layer, or a “convention,” that builds on the Bluetooth Low Energy (BLE) Standard. Apple has spurred an ecosystem around iBeacon by doing several things, which all feed into each other:
- Baked support for iBeacon into its mobile operating system (iOS) so that APIs are readily available for developers.
- Included support for background notifications at the OS level, so that push notifications can be triggered in certain situations, but without killing your phone’s battery.
- Provided a certification program to enable hardware manufacturers to create iBeacon-compatible hardware. This allows third-party manufacturers to provide iBeacon-compatible hardware of all shapes, sizes, and form factors, At last count, there were more than 50 suppliers of iBeacon hardware.
- Enabled every iOS device to be an iBeacon. This has many potential uses, from iPad-based POS systems welcoming you to a store, to the Hailo App letting you know that you can pay by Hailo.
- Ate its own dog food, by using iBeacon with their Apple Store App in all their US based Apple Stores.