You’ve heard of beacons. Then there’s iBeacon, Eddystone, and what else? Here’s your primer to get started understanding iBeacon vs. Eddystone, their histories, and what makes them each uniquely cool.
A beacon is a small device that transmits a Bluetooth signal at regular intervals. This signal is broadcast in a certain format, a communication protocol that describes the string of characters and numbers that make up the signal. The two most common protocols that beacons use are iBeacon and Eddystone—and Kontakt.io supports both! However, despite being incredibly similar (in that they both power beacon technology) the two standards are also fundamentally different. Much like Google and Apple, they fill different spaces in the market and, really, aren’t fundamentally interchangeable. They’re both being great tools. Here’s what you need to know about them.
What is iBeacon?
The history behind the beacon’s initiatory protocol
In short: The iBeacon profile is the first, and currently most commonly discussed, communication protocol around. It is not a physical hardware but rather the language used to power the physical “beacon” technology we picture. Developed by Apple, it is natively supported in iOS and has deep integrations with the mobile OS. Although the iBeacon profile works on other mobile operating systems, it works best in the environment for which it was designed: iPhones and iPads.
The full story: iBeacon has been around since 2013. Apple first announced the exciting new platform at the 2013 Worldwide Developers Conference, though its release went almost unnoticed in a number of ways. In reality, it would take quite some time for other companies to build up an ecosystem of products and use cases that put the technology to work.
It would also take time for the world to understand the fundamental nature of the protocol. Due perhaps to public assumption that anything from Apple would function out-of-the-box, consumers continue to misunderstand iBeacon. The internet is full of opportunities to “buy iBeacons”—whatever that means. In reality, you’ll be buying a piece of hardware (often protocol-agnostic) and then choosing which language (iBeacon or Eddystone) to use.
To prove they’re not all talk, Apple activated iBeacons across their 254 stores in the US. This was followed by a number of early adopters with similar retail usages for the technology. Since then, the protocol has been growing in popularity and, more importantly, growing through different verticals.
How does iBeacon work?
In short: A beacon using an iBeacon profile contains a combination of letters and numbers, broken up into specific groups. Each code is unique for every beacon, and a mobile application will only take action when it recognizes the data related to that beacon. Once a beacon is detected by an application, some kind of action is triggered: a push alert to the home screen, a prompt to log something into the phone, connect to a server, and so on.
This is the iBeacon’s first major distinction from Eddystone: it has the ability to wake up apps on both iOS and Android. For some businesses, this is a huge deal. Users don’t have to actively have a program running. They don’t have to enter any numbers or scan anything. They need only have the overarching app installed. For stores in a mall, this could be one app for the mall or a larger app used by several stores around the globe. This is the catch: your users absolutely must have the right app installed. However, once they do, you can send and collect far more data. When users think about beacon technology, they picture iBeacon and the ability to completely automate the interaction from physical movement to receiving a personalized, location- and profile-based notification.
However, this exchange is much less magical and mysterious than it sounds. The beacon is simply broadcasting an ID number that is then used the related app and program to return results. It’s up to developers to make use of the simple beacon data.
More importantly, these are numbers simply assigned to a physical location. While numbers stay the same, the location with which they’re associated may be changed when necessary. Their importance lies in the database connecting identifier numbers with a physical location. This is true for both iBeacon and Eddystone.
iBeacon’s signal contains three main pieces of information.
- Unique Universal Identifier (UUID): the beacon’s most general information. For example, this beacon belongs to this person.
- Major: the beacon’s most general spatial information. For example, this beacon is located in store #8.
- Minor: a more minute piece of information. For example, this is the beacon in aisle 2.
Read more on packets and IDs here.
iBeacon for developers and techies
Best practices and more detailed information can be found on Apple’s own write-up about iBeacon. This is actually a very interesting, not so complicated, read, so if you’re just curious to read more about the technicalities, you can find it here.
What is Eddystone?
The history behind the open protocol
The Eddystone format is a new and open communication protocol developed by Google with Android users in mind.
We often compare beacons to a lighthouse; they’re just simple objects constantly sending out a signal. Perhaps that’s the reason Google named their beacon format after the Eddystone Lighthouse in the UK. More importantly, though strikingly similar to iBeacon, it is distinctly Google (or, at least, non-Apple). The protocol is now known for being “open,” created with the input and collaboration of several companies. Instead of being created to power highly specific user-facing apps, its key qualities are interoperability and long-term strength.
This is made clear in its relation and importance to the Physical Web. The Physical Web is more like the overarching idea we have about wireless connectivity. It’s a form the IoT could take—making the digital and physical work together through beacons.
In the end, though the two formats are often mixed up, they represent pretty different ways of using the IoT.
How does Eddystone work?
Much of how Eddystone works is the same as iBeacon. But there’s extended functionality beyond that. Eddystone exists as four different frames: Eddystone-UID, Eddystone-URL, Eddystone-TLM, and Eddystone-EID. The UID works more or less exactly as iBeacon does: it broadcasts a short code at a regular interval. Eddystone-URL broadcasts a URL that can be viewed by anyone with a Bluetooth-enabled smartphone whether they have your app installed or not, and Eddystone-TLM broadcasts some telemetry data about any attached sensors and the status of the beacon itself. This could easily be used to power data collection or triggers. In short, Eddystone does nearly everything iBeacon does with some added features.
Any Kontakt.io beacon can broadcast both Eddystone and iBeacon formats interchangeably using our packet interleaving feature.
Eddystone sends 4 packets:
- Unique ID (UID) is a unique static ID (similar to the UUID, Majors, and Minors) with two parts: Namespace and Instance.
- URL includes a compressed URL that can be directly used by the end-user (think Physical Web!).
- TLM is another packet not found in iBeacon. It contains telemetry data that’s great for fleet management purposes.
- EID is an added security measure similar to Kontakt.io Shuffling.
Read more on packets and IDs here.
Eddystone for developers and techies
Due to the open nature of the protocol, Eddystone can be used in a number of different ways. This write-up from Google is a bit more complicated than that from Apple, so casual perusers beware.
Real-word example unique to Eddystone and the Physical Web
One of our favorite examples combines beacons with public transit with the tech-loving city of London. Proxama is one of the first location service providers certified by Google engineers. They worked with Exterion Media, a major and international media company to deploy the world’s first consumer-focused Physical Web campaign in London using Kontakt.io beacons. Though this isn’t the first time Proxama used the Physical Web and Eddystone, it’s one of the first times the world has seen the technology in action in such a big and complex way.
Their MyStop program catered to passengers on London buses, sending information about transit times and updates including how close they were their selected stop. Instead of forgetting their stop or getting lost, that meant users could simply enter their destination and wait for notification. On top of offering cool and useful information, this had the added benefit of being done through Eddystone instead of iBeacon—meaning branded and unwanted content can easily be silenced or ignored altogether.
Which one, which one?
The differences between the two are minor enough that end-users will likely not know the difference unless you’re implementing a Physical Web-based campaign. However, the coding and capabilities are a bit different as are their speculative outlook for the future. Apple is great at doing Apple: iBeacon is great at being relatively simple to implement. It’s also a proprietary software totally owned and controlled by Apple. Eddystone is going the other direction. They’re open to developers and published openly on GitHub. But it may not be so easy to implement. Eddystone also has those extra packets used for fleet management and security (though you can also use other tools like Kontakt.io shuffling to achieve similar effects).
The final decision may come down to your developers and what they want to work with, but this should give you a better understanding of what sets the two apart. Plus, with Kontakt.io’s packet interleaving, you don’t have to choose between iBeacon and Eddystone.
Moreover, there are more formats on their way. Though none have yet to pick up traction, it’s likely those looking for more specialized options will find more formats available in the future.