




These moves by Apple suggest that it’s reaffirming its belief in tightly controlling the user experience. It’s doing so by preventing developers from doing stuff that’s easy on Android.

Beacon Detection: How It Works

Bluetooth LE beacons transmit very little information: a unique ID number, power signal and some other data. This small packet of data is what makes Bluetooth LE low energy – your phone doesn’t need to parse a lot of information in order to detect a beacon, and the beacon doesn’t need to transmit very much to be detected.

When your phone or tablet detects the signal, it knows that a beacon is nearby. Based on this detection, an app on your phone can be programmed to interact – opening up a video, say, or downloading a coupon from “the cloud”.

Your phone is able to make decisions about what content it will display to the user based on which ID number it “hears” – a combination of a UUID and a major/minor identifier.

Closed UUIDs and Beacon Hijacking

Apple has always restricted the ability to randomly poll for beacons. In order to program an app that detects beacons, you need to specify which beacon your app is listening for. You couldn’t swap in wild cards for an actual UUID, you needed to specify the actual UUID.

Android, on the other hand, allowed you to scan for beacons that aren’t your own. This capability gave rise to initiatives like Wikibeacon (a subject for a coming guest post) which collects the data from apps that scan for all beacons in the vicinity.

The ability to scan for beacons that aren’t your own leads to concerns about hijacking.

Beacon hijacking is the concept of one app responding to someone else’s beacons. In theory, an app that can detect any beacon can detect a competitor’s beacons. I can own a shoe store with a beacon inside. In theory, if my competitor can scan for beacons and learn my UUID number, that same competitor can send messages to customers when they’re in my store.

Closing Your UUID Can Crash Your Android Phone

Addressing this concern, companies like Gimbal built beacons around one of the security options in the Bluetooth profile: the generation or transmission of random UUIDs. In the case of Gimbal, we understand that their beacons cycle through a series of random UUIDs in order to prevent beacon hijacking.

Unfortunately, this approach isn’t kind on Android devices which have a limited capacity to ‘buffer’ so many UUIDs, causing the phones to crash entirely requiring a factory reset as demonstrated in this video:

Apple Rejects Manual Input of UUIDs

We’ve been receiving reports that Apple has recently taken its “lock down” of UUID scanning a step further. Before, you needed to specify the UUID numbers you were scanning for in your app, but you could also manually input those numbers.

But now, Apple is rejecting apps that have this functionality. Awwapps is one of the documented cases of this rejection:

With the upcoming updates of our iBeacon apps Launch Here and Travel Radar we will remove the option to manually add and edit iBeacon credentials (UUIDs, Major ID, Minor ID). This is not our choice. We do this to keep the apps in the App Store. We’ll do our best to come up with other options to add your iBeacons – better options…We will improve on this and extend support to more iBeacon vendors…Please note that a general scanning of all iBeacons around is not possible on iOS. We rely on your input to cover all commonly used iBeacons.

The company sees it as valuable for the user experience, but a significant shift in Apple’s policy nonetheless:

To clarify, we have full understanding for this newly enforced policy. iBeacon credentials really aren’t something that should be exposed to casual users. But to be honest with you we would have liked to keep the manual entry around just in case you need it. Unfortunately this is not an option. We are convinced that going forward as harsh as this step may appear now will lead to a much better user experience. It will open up casual iBeacon applications to more people, especially those who are less tech savvy. The app updates bringing this change are not ready to ship quite yet. But this is a significant change, so we wanted to give you this notice upfront. If you have any questions or additional ideas, please let us know. We always appreciate your feedback a lot.

Will Apple’s Lock Down Go Further?

While the change might seem minor, it’s potentially significant in other ways. It’s a very rare case where a user would want to manually input a beacon UUID number.

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.

Share Your Thoughts


What do you think? By preventing users from manually entering UUID numbers on Apple apps, is the company making a shift towards a more closed beacon ‘ecosystem’? Will Google and Apple fork? Does the Apple approach of trying to prevent beacon hijacking lead to value, or does a more open system create an easier path to development and improved user experiences?

19 Responses to “Apple and the Closed System: Is Apple Slowly Locking Down iBeacon?”

  1. I think it makes sense not to allow end users to add/edit the UUID a APP is listening for. But how does this “prevent” a competitor from using another a device (non apple) to get the UUID and add it to their APP as another UUID to listen for via an update?

    Isn’t there a way to mask or encrypt the UUID to the phone?

    If not, then its open season on any beacon put out there and almost forces out use cases wanting (or needing) to use 1 UUID.

    The only sure way to prevent such a thing is to create a registry of UUIDs (like domains) that can only be used once. Making sure that each and every app has thier own UUIDs and there is never any cross over – nor would it matter if I got my competitors as I would not be able to enter it into my APP and listen for those beacons.

  2. Great comment Joel.

    To be clear about UUIDs…if you randomly generate a UUID all seven BILLION people on the planet would need to generate 500 MILLION UUIDs before there’s a 50% risk of one being duplicated.

    So there’s very very very very little risk of two people choosing the same UUID….what’s of greater concern is deploying beacons with the same UUID as the manufacturer’s “delivery setting” (e.g. how many beacons are out there with the exact same Estimote UUID)

    Yes on masking – which is my point really, because you can “pair” your phone to the beacon which opens up the remote possibility that Apple will introduce some kind of pairing requirement for iBeacon that locks out Android – very very remote but still possible.

  3. For custom built applications, this really shouldn’t be much of an issue. Generally coders load beacon identification info from an external source since they need to have the ability to update/cycle beacon info without having to deploy updates to the application itself. A simple json file example is here: . When I need to switch out beacons, I just update this JSON file and the new info is loaded up by the app when it is opened. Apple still allows this and it is hard to imagine this policy changing.

    However, for universal beacon management tools like, Apple’s new policy is going to present a major problem, which won’t be easy to overcome. It will likely require a rethink of the entire architecture of the app.

  4. Hi Doug,
    thanks for your post. I’m experiencing the same problem with Apple and my very new DropBeacon 1.0.0 app which is currently available on the Apple App Store. The app supports editing the UUID, major and minor IDs. Since it is v1.0.0 there was a bug in the app resulting in a crash on iOS7 while starting the advertisement. I fixed it and submitted v1.0.1 2 days later. Now they rejected the app, since they no longer want editor functionality for UUIDs since a user can spoof beacons now. Once I remove the editor functionality the app will be approved. I tried to leave only the three fixed UUIDs in which are used in their AirLocate sample app and left the option open to change major and minor IDs. Lets see if they still reject. If they do so, I really need to remove the editor and use fixed UUIDs :-(

    I don’t know what the problem is. There is no means on iOS to scan for “unknown” beacons around. Even if you scan von BLE devices, such as iBeacons, CoreBluetooth is hiding the manufacturer data where the UUIDs are encoded.

    I’ll let you guys know how I need to change my app in the end. What about BLExplr? Will they reject the next update to v1.6.1 as well?

    Best regards,

  5. Look forward to hearing your update Michael.

    The larger question is whether this is a policy change for ‘anti spoofing’ or perhaps related to the coming developer conference – maybe they’re about to make a move into more transaction-oriented beacons? Where there’s some reason to start ‘locking down’ beacons. I guess we’ll see!

    Jody is right – cloud based systems still provide a way to add UUIDs etc. on the fly. Proximity Kit being another example.

    Slightly mystifying…but they often either play a longer game or implement policy changes that make sense only to them :P

  6. This move by apple tries to put some limits on apps that scan for beacons in an ad hoc fashion which I think is a good thing overall. It does not really eliminate the possibility of spoofing or capture of UUIDs, but it helps make it less access able to the average passer by.

    We will have to see if this leads to any other tighter controls around iBeacons but I doubt it. It is in the best interests of all involved to keep the ecosystem healthy and reduce chaos.

  7. I think the ability to “couple” an app to an iBeacon should not be feared. It will not be for all app/ibeacon pairings but this can be a powerful way to secure a beacon to an app using peer to peer communication. Apple’s multipeer connectivity framework is a powerful way for devices to connect and open iBeacons ranging can be way to trigger secure communication between such devices to allow for richer and more secure communication without compromising open access to iBeacons. Android will need to keep pace. Stay tuned :)

  8. Artur Kiulian

    Closing Your UUID Can Crash Your Android Phone
    Its not changing UUIDs that crash anrdoids, its their MAC addresses which android are limited to

  9. Alexander Wehmeyer

    Hey Doug,
    Thanks for your post. It gave me more insights about questions I’ve already asked myself.
    I want to reply on Joel’s comment. I like the idea of creating a registry of UUIDs to prevent hijacking. Nevertheless isn’t it necessary, that there has to be a verfication if the specific beacon with his UUID is unique? Therefore we need a working internet connection to check if the beacon is unique, right? I liked the fact that BLE allows location-based advertising (maybe only in a simple form) without any server communication. Of course most of the apps are only working well with a working mobile data service, but without it beacon hijacking could be still possible.

    [Note: I’ve just thought about a beacon use-case in a mall-located store without any data service. Unfortunately a imaginable situation here in Germany]

  10. This is an extremely short-sighted move by Apple. Given there are no such restrictions on Android devices, Apple is effectively ceding the entire BLE ecosystem to Android. I’ve been an Apple developer for 36 years and starting to see them seemingly trying to move back into a completely closed and restricted ecosystem really saddens me.

  11. Jai Jaiprakash

    I had my app rejected – saying that information unlocked in the presence of a beacon should be available without the beacon. Does anyone have a similar experience? In my case, the app is designed to provide certain information only the presence of the beacon and it would defeat the purpose of the app to make it available without actually being away from the beacon. So I am surprised by this response from Apple. Thanks.

    • Whoa. That is very surprising. It defeats the purpose of having beacon activated content. Would it work to dim/disable the content and then activated when in range of the beacon?

      • Jai Jaiprakash

        Here is their comment :
        Thank you for your response. Basically, the app needs to provide an alternate way for a user to see the information without being at the beacons. The beacon aware feature is fine, just not as the only way to access the data. We look forward to your resubmission.
        I asked for clarification statements on what extent of data…and whether it has to be the same GUI. Am yet to receive a response.

  12. Hans Blaauw

    Interesting dicussion but the flaw is in the iBeacon protocol at first. Like SSID’s on WIFI routers, all iBeacon from several manufacturers are delivered with the same UUID which causes a big problem. If the purchasers don’t change the UUID and they attach some sort of app. or content to it all app. listening for that UUID would serve content.

    It is my believe there should be a central repository like EAN or DNS. Right now there are hundreds of beacons out there with the same UUID and that can cause problems.


  13. iBeacons are primarily intended for the app detecting proximity to something such as a store with offers. If Apple lock down iBeacons to effectively only iOS devices then the store owners (etc) will then only be able to advertise to the subset of clientele that have iOS devices. In that case iBeacons lose their value to the very people that will want to use them, and hence iBeacons may become a forgotten technology if Apple continues down this path. Confused by their actions.


Leave a Reply
