Apple Cracks Down on iBeacon for Android

Apple is cracking down on associations of Android devices with the iBeacon spec.

The move may hint at a larger war to own variations of the standards by which our phones ‘hear’ Bluetooth LE (BLE) beacons.

Vendors have started complying with guidelines set by Apple and have, as a result, been forced to ‘scrub’ their products of any references or connection between Android devices and their detection of iBeacon protocols. The net result is to create new difficulty in programming an Android device to hear an iBeacon…and a potentially growth of confusion in the market.

A Beacon is Still A Beacon if it Isn’t an iBeacon

To an outsider, the move probably seems obscure…or obvious. Why should an Android app be able to ‘hear’ an Apple iBeacon after all?

But an iBeacon is a device that transmits a signal using an open standard (Bluetooth) according to some specific criteria set out by Apple, and protected by all kinds of NDAs and trademarks. We know, for example, that a device which carries the iBeacon trademark is supposed to broadcast at a specific frequency.

But an iBeacon is still a Bluetooth device. In theory, any device with the right software and radio receiver should be able to ‘hear’ the signal.

For Apple, an iBeacon Isn’t *Just* BLE

But Apple clearly has a reason to think otherwise. Their moves seem to be saying:

  • We have a standard for BLE transmission, and have certified devices and trademarked a name under which that standard is carried
  • Association of that name and standard (iBeacon) with non-Apple products is a non-starter for Cupertino

This attitude may extend to the code. When Apple launched iBeacon with iOS7, they released SDKs to help developers detect beacons (and to turn any phone or tablet into a beacon). This code includes things like beacon ranging and distances….protocols whose algorithms are invisible to the developer. Apple may feel that their methodology for ranging beacons is also protected, and may be taking steps to avoid Android devices mimicking their approach. (This is, however, entirely speculative on my part).

Developers Forced to ‘Scrub’ Their Android Libraries

The increasingly closed-off nature of Apple’s iBeacon ecosystem came to our attention this week with a blog post by Radius Networks CEO Marc Wallace in which he announced that the company was taking down some of its products and documentation:

Prior to Apple introducing their iBeacon License Program, there were no clear guidelines from Apple on iBeacon trademark and intellectual property (IP) usage. Apple has since made great strides in formalizing their program and communicating the appropriate usage of iBeacon as a trademark and proper handling of iBeacon IP.

As a certified Apple iBeacon partner, we feel that it is important to respect the terms and spirit of our agreement. As a result, we have made the following changes:

  • Removed documentation describing the technical details of iBeacon advertisements.
  • Removed iBeacon-related libraries, SDKs and application implementations for mobile devices other than iOS devices.

We understand that you, our valued customers and partners, may be impacted by these changes. Please be assured that we also understand and appreciate how important it is to provide proximity solutions for multiple mobile device platforms, so we ask that you stay tuned, as we have additional exciting solutions that we will be introducing very soon. We believe that these new updates will ultimately create stronger and more robust solutions for our customers and our partners.

The post left the specific changes obscure. But the primarily deletion from the Radius product catalog was its ‘iBeacon library for Android’, shown in an older screen shot below:

By way of comparison, here is their current page:

Their GitHub repository shows the following:

Update: The Note From Our CEO is no longer active. See below.

Will Apple Pull Out the Patents?

At first, the iBeacon name was primarily window dressing for devices that transmitted signals according to the Bluetooth proximity specification.

Apple registered the iBeacon name, released the capacity to detect beacons with the launch of iOS 7, and then went mostly quiet. At the time, I speculated that Apple was either waiting to see how developers and manufacturers would use the capability before deciding on its own strategy, or perhaps didn’t realize how quickly the ‘becosystem’ would grow.

But they’ve slowly tightened up their claims to the iBeacon name and the IP that drives it.

The latest moves follow recent changes in their app approval process, in which the company started to reject apps in which the end consumer could input beacon UUID numbers. At the time, we speculated that Apple might be increasingly shifting to an attempt to “lock” its own version of beacons into its ecosystem:

But coupled with this change is another app approval policy that’s rarely noticed. Because while the specification of iBeacon would seem to suggest that Apple requires all beacons carrying the iBeacon trademark to have an “open” transmission, the reality is quite different.

Apple IS in fact allowing secure ‘coupling’ of app to beacon through the use of non-iBeacon protocols.

In other words, Apple is quietly allowing apps to securely “handshake” with an iBeacon, creating a secure connection between phone and beacon and preventing the UUID number from being publicly broadcast to any device other than phones with the requisite app.

These two things may lead to a fork between beacons that are configured to transmit to Apple devices and “open” beacons that, while vulnerable to hijacking, can’t even be ‘seen’ by Apple devices. If Apple makes further moves in the direction of closing off which beacons a device can listen for (and how) it’s possible that the iBeacon trademark (which is, for now, more of a branding benefit than an actual one) might soon represent a closed ecosystem of beacons that work with Apple devices and a parallel (and more open) system of transmission to Android phones.

But where might Apple go next?

The company owns a significant portfolio of patents related to iBeacon technology including some of the more common use cases. Patently Apple reports, for example, that:

Apple’s patent FIGS. 15A-G show embodiments of several different types of location-based content that may be provided to a media device in accordance with the principles of the present invention. FIG. 15A indicates various location-based content that may be provided in connection with a merchant that sells goods and articles of manufacture. For example, a user may access music (e.g., being freely broadcast by the establishment or for sale on content source), advertisements (e.g., coupon specials, video advertisements, and audio advertisements), event calendar (e.g., to learn of exciting new events that may be occurring at the merchant), virtual card information may be exchanged, podcast, general information on merchant (e.g., return policies), product information (e.g., graphics of products, reviews of products, etc.), or any other suitable information pertinent to the merchant.

The patents are primarily focused on communication of data wirelessly and so may be a narrow subset of current iBeacon use cases. But Apple clearly has ammunition in its patent armory should it choose to use it.

It’s Not the Device, It’s the Ecosystem

There was rampant speculation this week that Apple would launch its own iBeacon device. It arose from the discovery of an FCC filing for a USB-powered beacon.

I don’t personally see the device as anything much more than an internal tool at Apple….there’s nothing in its specification that hints at a mass market product.

The real moves that Apple is making aren’t around producing devices, they’re in a slow creeping enforcement of its specification, trademark and IP.

One Android “iBeacon library” has been scrubbed. What will follow?


The post at Radius has since been taken down, possibly to repost it to the main blog. We’ve reached out for comment. The full post is reproduced here:

Share Your Thoughts

Join our weekly e-mail list for more on iBeacons. Join the conversation on Twitter, or connect with me on LinkedIn.

Android “take-down”? Or simply a trademark enforcement measure? Is Apple making substantive moves to ‘close off’ iBeacon? I’d love to hear your thoughts and comments….some of this is shrouded in layers of shadow!!!

9 thoughts on “Apple Cracks Down on iBeacon for Android

  1. Let the payment and indoor navigation wars start. Apple is not just after Google Wallet to become an universal payment provider. It’s also about the huge indoor location market, Google Maps has no real access to at the moment. Think iOS 8 and Apple’s new core Location Features.


  2. The action by Apple is disappointing from a cross platform development perspective, but unsurprising given Apple’s track record regarding intellectual property. I suspect they’re entirely within their rights so I guess we just accept it and move on.

    My main concern is what effect this course of action will have on the nascent beacon ecosystem; fragmentation and forking of existing standards rarely leads to a happy place – remember Microsoft’s “embrace and extend” policy for web technologies anyone? We have the tools to build something extraordinary here, and if a significant portion of the user population are locked out or offered an inferior experience purely because they chose a different platform I think that would represent a missed opportunity for all.

    On the subject of Radius Networks, they’ve played a significant role in popularising beacon development, getting many developers up and running (myself included). I’m sure they didn’t take this decision lightly and I hope they’re back in the cross platform beacon space soon.


  3. OK, first of all let me say that we are also an iBeacon certified partner and we have seen no efforts from Apple to enforce an Android “take-down”. Maybe our turn hasn’t come up yet, but I doubt it – as much as Apple want they can’t really hide iBeacon devices from Android phones, it’s all still BLE. Now there is nothing stopping them from enforcing the trademark only on iOS, but the practical effects will be minimal – a simple rewording on the website and product documentation can be made to work around that issue. Especially as iBeacon hardware manufacturers we can’t control what device receives the iBeacon advertisement and what OS it is running – iOS, Android or anything else.

    What is happening in my opinion is that Radius Networks have simply decided to further develop their IP without disclosing it – it’s ultimately their decision what to do with their code, and open-sourcing their really good Android library has pushed the industry months, if not years forward. Their contribution is huge, but in doing so they have also helped create a lot of competition in the space which ultimately is a good thing but right now it only creates just a lot of noise.

    Now all vendors will need to implement their own Android support and proper differentiation can begin. The stakes have been raised once more – no need to panic, it’s just a sign of a slowly maturing industry.


  4. I love how you pretend that you could use Apple’s Trademark on a device that Apple
    wouldn’t approve.
    Apple also forbids reverse engineering which seem someone conveniently released to the web
    to faint ignorance to put in Android. Wonder you need Google’s permission for that as well.

    Cross Platform. I am sure Apple well get to testing on Android as soon as possible.

    You can’t even develop for HealthKit or HomeKit without MiFi license and they
    are littered with perfect secret encryption so iBeacon will have the same kind of thing.

    Trying to pretend otherwise is disingenuous at the least or fraud of major proportion.


  5. The article makes a lot of interpretation and it is not clear to me if Apple would shut down anyone that picks up iBeacon protocol on Android. I have recently checked Estimote and the Android iBeacon SDK is still available. As Vladimir pointed out, is it just a move from Radius to further protect their IP?
    What is exactly protected on iBeacon? Is it the payload (PDU)? Is it the behavior of ranging? (can that be patented?). The GAP in BLE spec allows to change the advertisement on the fly, nothing would prevent another company (e.g. Google, Estimote, Radius…) to advertise an iBeacon payload and after the advertisement event (20ms), advertise a different payload, using the same UUID in both.


  6. Fully agree with Vladimir. The only concerns from an Apple point of view might have been the use of the trademark, but I think as Valdimir point out that it is more a move to further protect their IP and raise the bar. @ubudu we have both IOS and Android SDKs and definitely building the Android SDK was more challenging both as you need to take care of the lower level bluetooth stack and build a service deaemon tasks that are handled by Core Location iBeacon Framework in IOS.
    Furthermore it comes after Google IO where announcements were made on new API functionalities to handle BLE advertising in the core Android SDK and more opportunities to link to Android Wear etc…So I expect that all providers of Android SDK will have to review their approach and explore the new APIs functionalities that might be more efficient/ reactive because @system level. This won’t be trivial as you might want to support also devices that will be in 4.3 or 4.4 Android system. The lag in Android in which a new release is broadly deployed to the user base is much longer than for IOS because it evolves also validation for the carrier companies. There is a cool infographic explaining the process in HTC website .
    As Validmir pointed out and also Doug after IOS 8 release, the bar for playing in the i-beacon and contextual aware platforms solutions is raising, it is a normal and expected evolution and it will clear a bit of noise today and rewards those who have made investments and developed distinctive features. Having said that, I strongly believe we are at the beginning of the new era and there are lot of new ideas and business models to be explored.


  7. Apple’s move to formalize their iBeacon License program and communicate the appropriate usage of iBeacon as a trademark of iBeacon IP is disappointing from a cross platform development perspective. But with the recent release of AltBeacon as a way to accelerate beacon adoption among non-iOS devices by Radius Networks, beacons are currently poised to really break out among android devices. Moreover, by providing developers with a new suite of tools and references that make it easier to develop apps that “listen” for beacons , AltBeacon will definitely go a long way in bringing parity to beacon development. Adding on to this, Apple’s iBeacon framework were found to actually perform better with Android especially when it comes to battery life, according to a recent report by Aiselabs. Given these two facts, beacons are currently poised to really break out among android devices.


  8. Solution: make the beacon transmit an advertisement resembling an ibeacon and then transmit one that is alt beacon. since droid doesn’t obscure the mac address it will happily receive pings from both broadcasts but poor apple will have to deal with half the data for ranging.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s