Need the history of iBeacon and Eddystone and what makes them different? Be sure to follow this up by visiting our Knowledge Center and learn the basics about protocols!
*Find out how are Eddystone and iBeacon different. Click here to download the complete Beacon Industry Report.
Like any other technology, beacons need a protocol that facilitates the integration of manufacturing, programming, transmission and general functionality. Every tech product needs the rules of the game to be defined so that parameters and specifications are clear to anyone who wants to join. The creation of a standard for the growth of any early-stage technology helps to promote it focusing development around the protocol and preventing incompatible standards from fracturing the market and confusing consumers.
We’re all familiar with industries in which competing standards resulted in showdowns that produced a winner and, well, everyone else. Think of Blu-ray’s victory over HD DVD. Protocols like USB, HTML, 4G and a long list of others became industry standards in similar ways after rivals faded away. For those products, the market demanded a single standard for greatest efficiency. One got pushed to the top and others got pushed out the door.
There are, however, instances when similar standards occupy the same market space but accomplish tasks in different ways and with distinct advantages and disadvantages. Both mp3 and FLAC are audio formats but they occupy separate niches and are not in direct competition.
Both solutions offer the same utility although they may each offer certain benefits the other does not.
When things like cost and performance are basically identical, consumers often show no strong preference for one or the other. The choice between Coke and Pepsi rarely ignites much passion because we see them as substitutes for one another.
This is the scenario that most closely applies to the two main standards for Bluetooth beacon communication, iBeacon and Eddystone. Both of them are broadcasting protocols based on Bluetooth 4.0, both of them fully support beacon deployments and they both offer essentially the same functionality while featuring small extras the other does not.
They’re also both backed by tech giants who supply the protocols as a way to bridge the physical and digital worlds.
It’s important to remember that neither iBeacon nor Eddystone are pieces of hardware. You can’t hold them in your hand. They are software protocols that provide the communication standards for beacons made by third parties. Beacons - the hardware part of beacon deployments - can support one format or the other or both. Think of iBeacon and Eddystone as the languages that the devices speak when they communicate with the world.
Two big players are behind the most commonly used protocols for those small devices. Let’s take a look at who they are and how their standards for broadcasting beacon signals compare.
At its 2013 Worldwide Developers Conference, Apple noted, almost in passing among bigger announcements, that it was releasing a platform for beacon development, iBeacon. In doing so, Apple laid the foundation for the emergence of the beacon industry and the world of proximity solutions. Almost immediately after it was released, iBeacon was installed in Apple’s company stores to highlight its retail applications and give curious early adopters a first look. iBeacon was also added to iOS 7, which meant it would be included in all iPhones and thus immediately accessible to millions. This significant user base was enough to jump-start the development community around beacons and accelerate interest in the potential applications of proximity infrastructures.
The fact that Apple’s name was attached to everything did much to push awareness of beacon technology into the mainstream even if it also caused confusion among those who thought that iBeacon was a physical product instead of a software platform. This is understandable since we’re talking about the people who gave us the iPod, iPad, iMac and iPhone - why wouldn’t the average person on the street think the iBeacon was the next must-have device?
As with other Apple products, the software that powers iBeacon is a proprietary, closed standard. Naturally, Apple made software development kits (SDKs) available for third parties to build beacon applications but the core of iBeacon’s code remains locked away in Cupertino, California.
You’ll find informative and detailed explanations of how beacons work here and here so let’s keep things in simple terms for our purposes by focusing only the role of iBeacon and Eddystone in beacon infrastructures.
The signal that iBeacon broadcasts contains three pieces of information and each has a role in how information from the beacon is interpreted and used. The four components are:
When data from applications is collected and analyzed, these three parts of the iBeacon signal make it possible to do things like track movement within a location (because, for example, you know that a device moved from the range of a beacon with one Minor to another) or know more about which store locations certain customers like to visit (because you know which app users interacted with a given beacon Major).
iBeacon is obviously native to devices running on Apple’s iOS and so it runs more smoothly and has slightly faster response times but it also supports Android devices, meaning that applications installed on Android phones will interact normally with iBeacon signals.
The Eddystone Lighthouse, just off the southwest coast of England, has been guiding ships to safety with its signal for centuries. Google thought this was the perfect concept to illustrate the role of beacons to a wider audience and borrowed the lighthouse’s name for the beacon communication protocol it introduced in 2015. With Eddystone, Google supplied an open-source protocol for developers of beacon apps working in the new world of proximity technology that Apple created two years before.
Eddystone brought a twist to beacon signals by making it possible to get more information in them through the use of three “packets”, spaces for additional pieces of information that can be used in various ways. The first of the three serves the same purpose as the information contained in the iBeacon signal as explained above, with codes used to identify who beacons belong to and where they’re being used.
The second data “packet” is what really made Eddystone stand out and is a big part of its appeal for developers - the ability to push a URL directly to a device without the need to create an application. Instead of needing an application that gets information from a server about what to do when a device is activated by a given beacon and then transmitting that command back to the device, Eddystone lets beacons send a URL directly to that smartphone or tablet. This ability to directly provide users with an online destination quickly became a common way to use beacons because it was so easy to do.
The third piece of data that Eddystone enables allows beacons to transmit information about the physical and environmental conditions that may threaten its performance like temperature and humidity and trigger actions based on those conditions.
Developers can choose to enable each packet individually, meaning that they don’t all have to be used if not needed.
Eddystone is native to Android, Google’s open operating system, and so any device running on it is ready to interact with beacons that “speak” Eddystone. Just like iBeacon, Eddystone is fully compatible with its “opposite” and so it supports iOS devices as well. Also, being open source means that developers can contribute to its development.
For all practical purposes, the differences between iBeacon and Eddystone are as small as the beacons they power. Any distinctions that do exist between them are on the margins of their functionalities. There’s no reason for an end user to be aware of anything regarding the slightly different ways that they support proximity solutions.
As noted, both protocols work with both iOS and Android devices. There is no issue of incompatibility involved with beacon transmissions to 95+% of all the smart devices in the world. On top of that, beacons are capable of broadcasting in both signals, or “interleaving”, thus ensuring that all beacons can communicate with almost every smart device on the planet regardless of the operating system it uses.
So, from the perspective of end users, the honest answer to the question of “What’s the difference between iBeacon and Eddystone?” is a simple “Not much.”
Each protocol can duplicate the functionalities of the other even if they take different paths to get it done. To the extent that some of those paths are more direct than others, the difference in the time it takes to execute commands is only perceptible to machines and no end user will ever know the difference.
Developers of beacon applications might disagree a bit about the differences between the two protocols but mostly over technical things beyond the scope of our focus here and well beyond anything of interest to end users of those apps.
“Despite another big player joining the game, iBeacon is still the most frequently used beacon profile on Earth. It’s simple, mature, and supported natively by millions of devices around the world. In other words, it has everything needed to be loved by developers and businesses.” - Szymon Niemczura
On the other hand, he adds that “Eddystone will eventually unlock its full potential and give us many reasons to love it. Eddystone is still a young format, and it needs time to be fully explored, tested, and deployed. Some of Kontakt.io’s customers are already running proofs of concept with Eddystone. As we know from our experience, moving from POC to a final deployment can take as long as a year, so I’m sure we’ll soon see Google’s format winning in more deployments.”
The growth in the adoption of the Eddystone format has been dramatic in the short time that it has been available and the proximity industry is waiting to see when and if Apple will answer with an update in iBeacon’s functionalities. Apple’s relative silence on its plans for the next phase of iBeacon support means it’s still an open question but recent developments may have provided a clue into their plans.
If you keep up with such things, you will recall the criticism of Apple’s decision to remove the headphone jack in the new iPhone 7 and their introduction of Bluetooth-powered AirPods, wireless earpieces for listening to music or interacting with the phone. This change means that, from now on, iPhone users will have to enable Bluetooth when the AirPods are in use. Apple wasn’t the first to move in this direction, either - wireless headphones are already twenty percent of the market and growing fast.
“Ok”, you’re thinking, “but what’s that have to do with beacon protocols?”
Well, remember that beacon deployments run on Bluetooth too. Currently, less than half of consumers have their Bluetooth turned on, even in Apple’s home market. With numbers like that, it’s hard to get the biggest players in the advertisement market fully on board with beacons. Could Apple be using the iPhone 7 to drive Bluetooth usage, which in turn promotes beacon activity, which in turn drives interest in reaching tens of millions of iPhone users?
As full-time use of Bluetooth increases, and it will, the number of consumers who are reachable through beacons will rise dramatically. With numbers comes attention and it’s not difficult to imagine that differences between iBeacon and Eddystone will become much more important as two tech titans attempt to dominate this new space.
If the iPhone 7 was the first shot fired in a new era of beacon protocols, then things are about to get really interesting. Time will tell but as beacon deployments continue to grow in size and number in every business sector, we’re sure that the capabilities of iBeacon and Eddystone - and maybe the beginnings of a real rivalry - will grow with them.
Exploring the beacon industry? Get the complete report for free.