Beacon “protocol” usually means the layout of a small Bluetooth LE advertising payload. It does not define the whole service, guarantee background discovery or remove the need for application and operating-system support. A sound decision therefore starts with the receiving stack and the lifecycle of the installed hardware.
Bluetooth beacons do not use a single universal format to identify themselves. The data they broadcast follows one of several competing protocols, each structuring the packet differently and offering distinct capabilities. For anyone procuring or managing a beacon deployment, the protocol choice affects what your beacons can do, which devices respond, and how much flexibility you retain later. This guide covers the three protocols you will encounter in practice and explains how to select between them.
iBeacon: identifier model and receiving ecosystem
iBeacon is Apple's beacon protocol, introduced in 2013. It remains the most widely recognised standard in commercial deployments, largely because Apple devices have supported background scanning for iBeacon packets since iOS 7.
An iBeacon packet carries four key fields inside its manufacturer-specific data payload:
- UUID — a 128-bit identifier that typically represents your organisation or deployment. Every beacon in a venue might share the same UUID.
- Major — a 16-bit value used to group beacons, for example by floor or zone.
- Minor — a 16-bit value distinguishing individual beacons within a group, such as a specific exhibit or till point.
- Measured Power — the expected RSSI (received signal strength indicator) at one metre, used by the receiving device to estimate distance.
The protocol defines only one frame type. Every iBeacon packet follows this same structure, which keeps things simple but limits what a single beacon can communicate. You cannot, for instance, broadcast a web URL directly in an iBeacon packet — the receiving app must map the UUID, Major and Minor values to content or actions using its own logic or a backend lookup.
Apple controls the iBeacon specification and does not publish it as an open standard. Manufacturers license the format and use Apple's assigned manufacturer ID in the packet. In practice this means you are relying on Apple's continued support and on manufacturers correctly implementing the spec. Interoperability issues occasionally surface when cheaper hardware deviates from the expected packet structure.
Eddystone: useful legacy frames, retired discovery assumptions
Eddystone is Google's open beacon protocol, released in 2015 and now maintained as an open-source project. Unlike iBeacon, it defines multiple frame types that a single beacon can switch between during operation.
Eddystone-UID
Functionally similar to iBeacon, the UID frame carries a 16-byte Namespace ID (analogous to an iBeacon UUID) and a 6-byte Instance ID (analogous to the Major/Minor combination). The shorter Instance ID reduces the total addressable space compared to iBeacon's 32-bit Major/Minor pairing, but is sufficient for most single-venue deployments.
Eddystone-URL
Eddystone-URL places a compressed URL in the advertising packet. It was designed for the former Physical Web model, but current phones do not provide a universal operating-system notification journey for these frames. Use it only where a controlled receiving application explicitly supports the format; for a new app-free public interaction, NFC or QR is normally easier to explain, test and maintain.
Eddystone-EID
The Ephemeral ID frame broadcasts a rotating encrypted identifier that changes periodically. Only a server holding the corresponding encryption key can resolve the EID back to a stable beacon identity. This addresses a core privacy concern: an observer cannot track the same beacon over time because the identifier keeps changing. EID is relevant when you need to share beacon presence with third parties without exposing fixed identifiers.
Eddystone-TLM
The Telemetry frame broadcasts the beacon's own operational data: battery voltage, temperature, advertising count (how many packets sent since power-on) and time since power-on. This is useful for remote monitoring without needing to physically inspect each unit. Beacons typically interleave TLM frames with their primary UID or URL frames at a lower frequency to conserve battery.
AltBeacon: an open packet layout, not universal platform support
AltBeacon was released by Radius Networks in 2014 as an explicitly open, vendor-neutral alternative to iBeacon. Its packet structure is similar — a 128-bit ID, a 16-bit Major, a 16-bit Minor and a measured power value — but the specification is published openly and any manufacturer can implement it without licensing.
The practical reality is that AltBeacon has not achieved broad native platform support. Neither iOS nor Android scans for AltBeacon packets in the background without a dedicated app. Its value lies primarily in deployments where you want to avoid any single vendor's control over the protocol format, or where you are building a custom app that can specify its own beacon parsing logic regardless of what the operating system does natively.
For most UK retail, museum and venue deployments, AltBeacon is unlikely to be your primary protocol. It may appear as a supported format on multi-protocol beacons, but native iBeacon and Eddystone support on mobile platforms makes them the practical defaults.
Choose for the receiving stack, not for the logo
The decision should follow from your operational requirements, not from brand preference. Several concrete factors distinguish the two in practice.
Do you need app-free interaction? If your use case depends on reaching visitors who have not installed your app, Eddystone-URL is the only option that allows a browser to act on the beacon directly. Bear in mind that browser support for background beacon scanning is limited and has been reduced in recent Android versions, so test this carefully against your target devices and OS versions.
Is your audience primarily on iOS or Android? iBeacon benefits from deep iOS integration: background scanning works reliably, and the OS delivers beacon events to your app even when it is not in the foreground. Eddystone has stronger native support on Android, particularly for UID and URL frames. If you are building for both platforms, most commercial beacons support broadcasting both protocols simultaneously or switching between them, so the choice is not always exclusive.
Do you need telemetry data? If you want to monitor battery voltage and beacon temperature remotely, Eddystone-TLM provides this without additional infrastructure. With iBeacon, you would need a separate monitoring system or manual inspection to gather the same data.
Are privacy requirements a factor? Eddystone-EID's rotating identifiers are useful when beacon data is shared with partners or processed by third-party platforms. iBeacon's fixed identifiers mean anyone who can read the packet can track the beacon over time unless you implement your own encryption layer above the protocol.
Do you need multiple frame types from one beacon? A single Eddystone-capable beacon can alternate between UID, URL, EID and TLM frames. iBeacon beacons broadcast only one frame type. If you want a beacon to serve both proximity-triggered app content and telemetry monitoring, Eddystone handles this natively.
A common mistake is treating the protocol choice as irreversible. Most modern beacons are multi-protocol and can be reconfigured over the air. The more consequential decision is what your receiving app or platform is built to parse. Changing the beacon protocol after launch means updating your app's scanning logic and potentially your backend mapping tables.
Compatibility and migration checks before procurement
Native operating-system support determines how reliably beacons work, particularly in the background when the user is not actively looking at their phone.
iOS and iBeacon: Apple's Core Location framework handles iBeacon scanning natively. Apps can register regions based on UUID and receive callbacks when a device enters or exits those regions, even in the background. This is the most mature and reliable background beacon scanning path available. iOS does not natively scan for Eddystone or AltBeacon in the background — a third-party app must use Core Bluetooth to scan explicitly, which has stricter background execution limits.
Android and Eddystone: Android's Google Play Services include native support for Eddystone-UID and Eddystone-URL through the Nearby Messages API. Background scanning for Eddystone has been subject to change across Android versions, and Google has progressively restricted background location access in recent releases. Any Android deployment should be tested against the specific OS versions your visitors actually use, with particular attention to background behaviour.
Android and iBeacon: Android does not natively scan for iBeacon packets through a system API. Apps must use a BLE scanning library (such as the open-source Android Beacon Library) to parse iBeacon-formatted packets from raw BLE advertisement data. This works reliably in the foreground but is subject to Android's background execution limits and location permission requirements, which have tightened significantly since Android 10.
Web Bluetooth: Browser-based beacon interaction remains limited. Web Bluetooth can scan for BLE advertisements in some browsers on some platforms, but support is inconsistent, background scanning is not available, and iOS Safari does not expose BLE advertisement data to web pages at all. Any deployment relying on web-based interaction should be treated as a foreground-only, best-effort channel and tested thoroughly against your target device mix.
The practical implication is straightforward: if you need reliable background triggering on iOS, iBeacon is the only proven path. If you need native Android support without a custom scanning library, Eddystone has the edge. For cross-platform deployments, most teams build their app to scan for both protocols and select beacons that can broadcast whichever format the situation requires.
Before committing to a protocol, verify the scanning behaviour on the actual device models and OS versions prevalent in your visitor base. Manufacturer documentation and protocol specs describe what should happen; only device-level testing confirms what does happen in your environment.
Decision record to keep
Record the packet formats enabled on each hardware model, identifier ownership, configuration credentials, receiving libraries, tested device matrix and migration route. Where legacy Eddystone frames remain, document exactly which controlled application parses them and which retired Google services are not part of the design.
