Continuing our iBeacon series, we’re going to try to clear up any confusion around naming and standards – what are the differences (if any) between Bluetooth Beacons, iBeacons and AltBeacons? Will the original standard survive or will proprietary enhancements win out?

Bluetooth Low Energy (BLE) Beacons

Bluetooth Low Energy is part of the Bluetooth 4.0 spec that defines a number of profiles, describing what particular types of device should be able to do and how they should work. Bluetooth 4.0 has also been given the smart branding.

The devices that have come to be known as beacons (or iBeacons) implement the proximity profile (finalised in 2011) that lets other devices detect when they are nearby.

Importantly, this means beacon behaviour is well defined and described by a standard, so that devices and software from different companies can work together. So why does Apple need to certify products before they can be iBeacon branded?


iBeacon is a brand and trademark applied to bluetooth low energy beacon technology by Apple, who certify products as iBeacon compatible, but do not manufacture iBeacons themselves (yet). Companies can apply to carry the branding on their products and will be given the required specifications only under a Non-Disclosure Agreement.

The only technical difference appears to be that iBeacons should transmit an Apple-defined prefix, that would not be required to comply with the original BLE standard.

So, right now, there is no practical difference between iBeacons and non-Apple certified BLE beacons. However the fact that Apple has introduced an identifier means that they could potentially lock down iOS to only recognise iBeacon certified devices. Though this might seem unlikely, I believe it’s inevitable they will try to differentiate the feature set of “iBeacons” from plain old BLE beacons in some way in the near future. It also means that you won’t be seeing any Android software or hardware branded as iBeacon anytime soon (more on this in the next section).

Finally, it’s worth noting that Apple have been granted a number of patents around iBeacon technology (with more likely to emerge), and have made filings relating to an Apple iBeacon device.

Whether Apple’s iBeacon certification continues to be compatible with the open standards, or if they will see enough commercial opportunity in differentiation remains to be seen.


One side effect of Apple’s certification requirements was that companies had to pull or rename Android software they may have been attaching the iBeacon label to. This led to Radius networks dropping their iBeacon Software Development Kit for Android.

They themselves brand their own beacons RadBeacon, however they are in fact Apple certified as iBeacon compliant.


Perhaps as a result of the above, Radius Networks seemed to sense a move towards proprietary customisation and away from Android, and introduced the AltBeacon open standard (more) as an open alternative to iBeacon.

Because there is no open and interoperable specification for proximity beacons, Radius Networks has authored the AltBeacon specification as a proposal for how to solve this problem.

This specification is simple and compliant with the original Bluetooth 4.0 standard, using data originally defined as Manufacturer Specific Advertising Data to squeeze a bit more into the messages transmitted by by AltBeacons.

Since the standard is open, manufacturers can build products that work with each other, but there is also scope for them to add proprietary data that could (for example) lock their own hardware to their own software, or be used to provide additional features.

It seems unlikely that AltBeacon will be widely adopted as it’s attracting little attention, however it could gain traction if Apple attempts to significantly diverge from Bluetooth standards with iBeacon.

What About Everyone Else?

Beacon manufacturers generally seem to be obtaining iBeacon certification whilst continuing to tout the cross-platform nature of their products.

  • – “Works with iBeacon, Android, and Bluetooth Smart”
  • Qualcomm/Gimbal – “APIs for both iOS and Android”
  • Estimote – “Full iOS and Android compatibility”

This is good news, with suppliers adding value via their software offerings, end-to-end solutions and product ecosystems rather than attempting to hijack the standard.

What Does This All Mean?

Right now, iBeacon is an exercise in branding, with hardware and software from major manufacturers able to work together using the original Bluetooth standard for proximity. Further, the biggest players seem to be promoting this fact rather than trying to diverge in order to stand out.

However, it’s worth remembering that Apple devices dominate others in the potential audience for beacon-related products and services. When we wrote about this before an estimated 90% of iPhone owners vs 18% of Android owners could use beacon apps.

Currently those figures are around 45% for Android and 96% for iOS, and with Apple leading deployments, and better integrating the experience of using beacon-enabled apps in its operating system, they may have the leverage to dictate future developments.