iBeacon™ or Eddystone™?

iBeacon™ and Eddystone™ are two popular beacon data transmission standards (a.k.a. profiles) in use today. While iBeacon is a proprietary standard owned and promoted by Apple, Eddystone is an open standard promoted by Google. Both standards come with their own custom API’s to scan and manage respective beacons. 

Many Beacon transmitters today support both these standards, and some even transmit concurrently in both formats. xChannel API supports both these standards seamlessly from an application point of view. However the end user experience differs slightly between the two.

So which one should you use? The answer depends on a few things. Below we summarize some of the key differences between iBeacon and Eddystone stack, and how they are handled by iOS and Android devices.

 

Device Compatibility

    • Both message formats can be received by iOS and Android devices
    • iOS devices have a deeper integration with iBeacon messages, while Android devices respond better with Eddystone messages 1)Eddystone URL messages can send notifications in Chrome on Android. On iOS they appear in the Today view, but don’t generate any notifications
    • Native support for iBeacon messages on iOS started with iOS7.0 while the native Eddystone support on Android started with 4.3.2 2)The API support for Eddystone are available in earlier versions of Android. The client side “Nearby API” to scan Eddystone beacons was rolled out with Google Play Service v7.8. But the Chrome notification support was added from Android 4.3.2

 

Functional Differences

    • Frame Types (Data Payloads) – iBeacon supports only one type of frame – which contain a unique ID (UUID). So they work only when there is an app scanning for these UUID installed on the user’s device. Eddystone on the other hand is designed to support multiple frame types. Today they support four different frame types – UUID, URL, Telemetry and Ephemeral ID. When transmitting UUID frame type, an Eddystone beacon behaves similar to an iBeacon. The URL frame type in Eddystone allows the Beacon to publish a preconfigured URL to all listening devices in its vicinity. These URL’s may be opened in a compatible browser (e.g., Chrome) on user’s device. So there is no need for an additional app to be installed on the user device to handle them.
    • App Launching – Because of its tight integration, iBeacon messages can launch an iOS app if it has expressed an interest in that iBeacon. Eddystone messages cannot launch an app on iOS, but they can wake them up if they are already running in the background.
    • Security – Data published by Beacons are generally transparent, and can be read by packet sniffer software. This makes them vulnerable to two types of security issues – UUID Hijacking and UUID Spoofing (more on these in a future blog). Eddystone EID frame type is designed to tackle this issue by allowing only the authorized app to read the contents of a beacon message. This makes them less vulnerable to beacon transmission related threat exposures. That said, many beacon vendors have built additional security features inside their hardware which makes them attractive for more secure use cases.

 

Operational Differences

  • Phone Battery Efficiency – Eddystone message scanning on iOS devices is implemented on CoreBluetooth API whereas iBeacon scanning is implemented on CoreLocation. Because of this, on iOS, scanning for Eddystone messages are more battery intensive as compared to iBeacon.
  • Performance/Range – Performance and range of beacons is an attribute of the beacon hardware, and in many cases, can be traded off with the device battery life. Many beacon vendors allow this to be configured at setup time.
  • Fleet Management – Eddystone provides a custom cloud based “Proximity API” to manage conforming beacon fleets. However most beacon vendors also provide their own management tools to manage their beacon fleets. Routine fleet management tasks involve beacon diagnostics, monitoring their battery levels, changing their attached data etc.

Summary

So where does all this leave us? Here are our recommendation:

  1. If you have a native app on iOS and/or Android, then go with a beacon configured for iBeacon and Eddystone UID.
  2. If you don’t have an app or if you want to target users who don’t have your app installed (on iOS or Android), then use Eddystone URL.

Want to know more? Please contact us to explore your options further.

References   [ + ]

1. Eddystone URL messages can send notifications in Chrome on Android. On iOS they appear in the Today view, but don’t generate any notifications
2. The API support for Eddystone are available in earlier versions of Android. The client side “Nearby API” to scan Eddystone beacons was rolled out with Google Play Service v7.8. But the Chrome notification support was added from Android 4.3.2
Contact Us

Send us an email and we'll get back to you asap.

Not readable? Change text.

Start typing and press Enter to search