Radius Networks has launched a new open standard for beacons today called AltBeacon, and with it is laying down a protocol that may become a de facto standard for developers who want their proximity beacons to do more than just work with iOS devices.
While initially targeted to Android devices, AltBeacon is an open specification and will generate innovation across a variety of platforms. It will go a long way in bringing parity to beacon development…an issue right now because Apple clearly has a head start with its iBeacon specification.
The company, which recently removed its “Android iBeacon libraries” (possibly under pressure from Apple, or at least the Apple licenses) is setting out to establish a set of tools that will make it easy for beacons to communicate with Android, Apple, Windows and other customer devices.
In a post about the move, CEO Marc Wallace explains the launch of AltBeacon:
Currently, no open, interoperable specification for BLE proximity beacons exists. Only proprietary specifications exist, which favor one vendor over another. We hope that AltBeacon solves this problem. We also believe we have created a specification that is more flexible and can accommodate different types of proximity beacon implementations and solutions that can benefit by not being locked into a specific format, such as rigid identifier lengths and additional payload space for critical information.
Released under a Creative Commons license, AltBeacon sets out to do two things: define a robust specification for device transmission (the packets that a beacon sends) and a suite of tools and references to make it easier to develop apps that “listen” for beacons.
Better than iBeacon?
The AltBeacon specification will leave developers who use Apple’s iBeacon specification drooling.
While Apple has made Bluetooth LE proximity easy to develop for and deploy, and while devices carrying the iBeacon name can be assured that iOS apps will run seamlessly with the beacon, there are limits. In particular, Apple limits how much of a beacon’s “packet” can be used with the iBeacon SDK.
But the power of Bluetooth LE is in its flexibility and simplicity. A device that broadcasts a BLE “packet” with a proximity profile can do a lot more than just transmit its TX power, UUID and major/minor values. Its advertisement packet can be customized to all kinds of use cases, making fleet management incredibly flexible and even embedding vendor or retailer-specific data that could be used client-side to refine the experience for the user.
But on Apple devices, you need to use CoreBluetooth to dive ‘deeper’ into the BLE packet. Developers therefore need to dance around using iBeacon, because of its ability to detect beacons even when the app is closed, and CoreBluetooth because of its ability to pull out and respond to additional data. As well, the beacons themselves can be certified as iBeacon or simply BLE, complicating the ‘stack’ for an iOS developer.
Going Deep with BLE and AltBeacon
AltBeacon brings greater transparency to what a beacon transmits and how that data can be used by Android, Windows and other devices. By helping to shift towards a shared standard for non-iOS devices, AltBeacon will empower developers to truly take advantage of what a BLE proximity beacon can do.
As Marc commented to me this morning: “Our real challenge is to evolve our tools to minimize the confusion and impact on the development effort. If beacons easily speak multiple transmission types and development tools painlessly integrate them across the respective multiple mobile platforms, everyone will benefit.”
So AltBeacon will stand confidently beside iBeacon as a new way to accelerate beacon adoption for non-iOS devices and will, it’s hoped, bring greater parity to the two platforms.
Share Your Thoughts
What do you think? Will an open standard like AltBeacon help bring parity between Android and iOS?