iBeacon vs AltBeacon: Which BLE Beacon Format to Use and When It Matters

The same $12 beacon sitting on your desk can broadcast iBeacon, AltBeacon, or both simultaneously. Yet teams spend weeks debating which format to “commit to” as if they’re choosing a religion. The real question isn’t which format is better. It’s which format’s ecosystem constraints will quietly shape your app architecture, your background detection reliability, and your App Store review experience six months from now. That’s the part most comparison articles skip.

This is a head-to-head comparison of iBeacon and AltBeacon at the protocol, ecosystem, and practical deployment levels. If you’ve already decided on BLE beacons and need to pick a format, or figure out whether to support both, this is the article that gets you to a decision.

What a Beacon Format Actually Defines (and What It Doesn’t)

A beacon format is a specification for the BLE advertising packet payload, specifically how bytes are arranged within the AD structure of a non-connectable undirected advertisement (ADV_NONCONN_IND). It defines three things: identifier fields, a measured TX power reference value, and the byte pattern that scanning software uses to recognize and parse the packet.

A beacon format does not define hardware, radio behavior, transmission interval, antenna design, or power management. This distinction matters more than most teams realize: format is a software/protocol concern, not a hardware concern. Most commercial beacons support multiple formats through firmware configuration. Choosing a format doesn’t lock you into specific hardware, and switching formats later is typically a firmware update, not a hardware swap.

With that established, let’s look at exactly what each format puts on the wire.

iBeacon Protocol: Structure and Ecosystem Lock-In

Apple introduced iBeacon in 2013. The payload structure is fixed and rigid by design:

iBeacon Advertisement Payload (within ADV_NONCONN_IND)
┌────────────┬────────────┬─────────────────┬──────────────────────┐
│ Length     │ AD Type    │ Company ID      │ iBeacon Type + Len   │
│ (1 byte)  │ (1 byte)   │ 0x4C 0x00       │ 0x02 0x15            │
│            │ 0xFF (MFG) │ (Apple's)       │ (2 bytes)            │
├────────────┴────────────┴─────────────────┴──────────────────────┤
│  Proximity UUID (16 bytes)                                       │
│  e.g., F7826DA6-4FA2-4E98-8024-BC5B71E0893E                     │
├──────────────────┬──────────────────┬────────────────────────────┤
│  Major (2 bytes) │  Minor (2 bytes) │  Measured Power (1 byte)  │
│  e.g., 0x0001    │  e.g., 0x0042    │  e.g., 0xC5 (−59 dBm)    │
└──────────────────┴──────────────────┴────────────────────────────┘

The identifier hierarchy is straightforward: UUID (16 bytes) typically identifies your organization or app, Major (2 bytes) identifies a venue or region, and Minor (2 bytes) identifies a specific beacon. You get 20 bytes of usable ID space plus 1 byte of TX power reference. No room for custom data.

Licensing: Apple requires a (free) iBeacon license to manufacture or sell hardware that advertises in this format. The license includes terms around marketing and usage. Apps that detect iBeacons don’t need the license.

The killer feature: iOS CoreLocation’s CLBeaconRegion API provides native background monitoring and ranging with no third-party SDK required. The OS itself wakes your app on region entry and exit, even if the app has been terminated. On Android, iBeacon packets are detectable via generic BLE scanning or libraries like the Android Beacon Library, but there’s no OS-level integration.

AltBeacon Specification: Openness and Flexibility

Radius Networks published AltBeacon in 2014 as an open specification. The structure is deliberately more flexible:

AltBeacon Advertisement Payload
┌────────────┬────────────┬─────────────────┬──────────────────────┐
│ Length     │ AD Type    │ MFG Company ID  │ Beacon Code          │
│ (1 byte)  │ (1 byte)   │ (2 bytes)       │ 0xBE 0xAC            │
│            │ 0xFF (MFG) │ (yours from SIG)│ (2 bytes)            │
├────────────┴────────────┴─────────────────┴──────────────────────┤
│  Beacon ID (20 bytes — partition however you want)               │
│  e.g., [16-byte ID1] + [2-byte ID2] + [2-byte ID3]              │
│       or [20-byte flat namespace]                                │
├──────────────────────────────┬───────────────────────────────────┤
│  Measured Power (1 byte)     │  MFG Reserved (1 byte)            │
│  e.g., 0xC5 (−59 dBm)       │  e.g., 0x00                       │
└──────────────────────────────┴───────────────────────────────────┘

Key differences start at the Company ID field: AltBeacon uses your own Bluetooth SIG-assigned manufacturer ID, not Apple’s. The Beacon ID (20 bytes) is intentionally unpartitioned. You decide whether to mimic UUID/Major/Minor or use a flat 20-byte namespace. The extra MFG Reserved byte gives you 1 byte for manufacturer-specific data (battery level, sensor flag, hardware revision).

Licensing: None. No proprietary license, no terms, no restrictions on marketing. Open specification.

Android ecosystem: The Android Beacon Library provides strong background monitoring and ranging for AltBeacon, effectively giving Android the same background wake-up behavior that CoreLocation gives iOS for iBeacon.

The catch on iOS: AltBeacon packets can be detected via CoreBluetooth’s centralManager scanning, but not via CoreLocation. This means no native background beacon monitoring. CoreBluetooth background scanning on iOS is heavily throttled: scan intervals widen dramatically, and detection latency can stretch to minutes. For iOS apps that need reliable background detection, this is a significant limitation.

Side-by-Side: What Actually Differs

Three differentiators matter most in practice. First: iOS background detection. CoreLocation monitoring is categorically more reliable than CoreBluetooth scanning in the background. This isn’t a minor difference; it’s an architectural constraint. Second: licensing. If you’re manufacturing hardware, Apple’s iBeacon license terms govern how you describe and market the product. Third: payload flexibility. That extra MFG Reserved byte and the freedom to partition the Beacon ID are meaningful if you’re building sensor-augmented beacons or need non-standard identifier schemes.

When iBeacon Is the Right Choice

iOS-primary or iOS-critical deployments. If your user base skews iPhone (retail, museums, stadiums, indoor wayfinding), CoreLocation background monitoring is a decisive advantage. The OS handles region monitoring at the system level, waking your app on entry and exit even after termination. No other approach on iOS matches this reliability.

Simplicity and ecosystem compatibility. The UUID/Major/Minor hierarchy is understood by every beacon management platform, every CMS integration, and every tutorial ever written. If your team doesn’t need custom payload structures, the rigidity of iBeacon is a feature. It reduces ambiguity.

App Store review. Apple’s review team is most comfortable with apps that use CoreLocation for beacon detection. Apps using CoreBluetooth scanning for proximity purposes can trigger review questions about background Bluetooth usage justifications. This isn’t insurmountable, but it’s a friction point worth knowing about.

Vendor ecosystem. Every major beacon hardware manufacturer (Estimote, Kontakt.io, Minew, and dozens of others) supports iBeacon out of the box. You will never struggle to find compatible hardware.

When AltBeacon Is the Right Choice

Android-primary deployments. Warehouse logistics, industrial asset tracking, manufacturing floor automation, enterprise apps running on managed Android device fleets: if iPhones aren’t in the picture, AltBeacon plus the Android Beacon Library gives you the strongest native-feeling background detection experience.

Licensing sensitivity. If you’re manufacturing beacon hardware and want full control over your marketing language, product positioning, and terms of sale, avoiding Apple’s iBeacon license removes a dependency. This matters most for white-label hardware manufacturers and OEMs.

Custom payload needs. The MFG Reserved byte is modest, just 1 byte, but combined with flexible Beacon ID partitioning, it enables use cases where you want to encode hardware state (battery level indicator, sensor trigger flag) directly in the advertisement payload without requiring a GATT connection. For sensor-augmented beacons or custom firmware projects, this flexibility is meaningful.

Organizational policy. Some enterprises and government agencies have procurement policies that discourage or prohibit proprietary protocol dependencies. AltBeacon’s open specification satisfies those requirements cleanly.

The Dual-Broadcast Strategy Most Teams Actually Ship

Here’s what happens in practice: most production deployments targeting both iOS and Android broadcast iBeacon and AltBeacon simultaneously. The beacon hardware interleaves both packet types across advertising slots, and each platform’s app uses its strongest detection path. CoreLocation on iOS, Android Beacon Library on Android.

The trade-offs are real but manageable. Power consumption increases modestly, roughly 10–20% depending on advertising interval. Effective advertising rate per format drops because the radio timeslices between packet types. Fleet management becomes marginally more complex since you’re configuring two payloads per device.

For most consumer-facing deployments where both platforms matter, dual-broadcast is the pragmatic default. You get CoreLocation’s reliable iOS background monitoring and AltBeacon’s open, flexible Android detection without asking either platform to compensate for the other’s weaknesses.

Making the Right Format Decision for Your Deployment

Format choice comes down to three variables: target platform mix, licensing posture, and payload flexibility needs, not hardware.

If iOS is your primary platform, start with iBeacon. If Android is your primary platform, start with AltBeacon. If you serve both, and most consumer-facing products do, dual-broadcast and let each platform use its native strength.

The most important thing to internalize: this decision is not permanent. Because beacon format is a firmware configuration, adding a second format or migrating entirely is a software update away. The beacons on your ceiling today can broadcast a different format tomorrow. Design your server-side infrastructure around abstract beacon identifiers rather than format-specific fields, and you’ll preserve full flexibility regardless of which format you start with.

Hubble Network connects BLE beacons to the cloud via satellite—no gateways, no terrestrial infrastructure. See how it works →