Making Money With Technology

Exploring iBeacons with iOS

April 1, 2014

  • Lextech Admin
  • 4

What is an iBeacon?

This seems to be the question everyone’s been asking lately! iBeacons are little more than Bluetooth Low Energy transmitters, and yet so much more. Practically though, they’re very unobtrusive devices that define a region of space with a variety of different properties.

For a more in-depth look, check out this awesome infographic Lextech has recently published.

iBeacon Properties

An iBeacon typically has 4 pieces of data it transmits. These are its UUID, Identifier, Major, and Minor. I’ll borrow Apples descriptions of those items, which you can find here for more information.

  • UUID – The device’s Universally Unique Identifier, a string 32 hexadecimal characters in length. Commonly created using uuidgen.
  • Major – An unsigned integer representing the most significant value in the iBeacon. We like to think of it as the iBeacon’s Category.
  • Minor – An unsigned integer representing the least significant value in the iBeacon. We like to think of it as the iBeacon’s Sub-Category.

Say for example we want to setup some iBeacons to denote which building we’re in, and which office we’re in. We might define the following:

  1. An iBeacon
    • UUID – BA18917F-8AEA-47B8-BB9B-B4B279161669
    • Major – 1 – Denoting our Chicago office.
    • Minor – 1 – Denoting the Receptionist’s desk.
  2. An iBeacon
    • UUID – BA18917F-8AEA-47B8-BB9B-B4B279161669
    • Major – 1 – Denoting our Chicago office.
    • Minor – 2 – Denoting the Conference room.

Using this format, we could define major 2 to mean our Lisle office, making a major-minor of 2-1 to be our Lisle reception area. Almost like the good old Super Mario Bros. level naming conventions!

Do note also that all of the iBeacons we’d use for this system would share the same UUID, as iOS is limited in what it can listen for. More on that in a bit.

iBeacons Define Virtual Regions

The power of iBeacons lie in their ability to denote a region of space. If you’ve found and learned from a iBeacon you can reason where you are, in whatever sense you’ve defined where to be. An iBeacon’s region is strikingly similar to that of a Geo-fence, which is an area usually defined with respect to one or more latitude-longitude pairs. And, as luck would have it, iOS has had a facility that supports geofencing for some time now – CLLocationManager. Using a CLLocationManager in conjunction with a sweet new CLRegion subclass, CLBeaconRegion, we can effortlessly listen for our user’s movements into, within, and out of an iBeacon’s bounds.

To request iBeacon notifications from iOS, we can do something akin to the following:

- (void)listenForiBeacon
    CLLocationManager *manager = [[CLLocationManager alloc] init];

    // we need to know when we interact with a region
    manager.delegate = self;

    // the iBeacons should all be broadcasting this UUID
    NSUUID *uuid = [[NSUUID alloc] initWithUUIDString:@"BA18917F-8AEA-47B8-BB9B-B4B279161669"];

    // more on this shortly
    NSString *iden = @"";
    CLBeaconRegion *region = [[CLBeaconRegion alloc] initWithProximityUUID:uuid

    // do stuff with the two

The code is pretty straightforward. We’re creating a CLLocationManager, and would like it to talk to our class, which presumably conforms to the CLLocationManagerDelegate protocol, allowing it to handle location-based event. Next, we’re creating a UUID and a CLBeaconRegion that uses the UUID. Interesting is the identifier property on CLBeaconRegion. This should not be confused with the UUID; rather, the identifier, which is usually expressed in reverse domain name notation, is used internally by our location manager, to differentiate between iBeacon regions.

Monitoring an iBeacon Region

In order to discover iBeacons, you have to monitor for them. This is extremely simple, doable in just one line of code, and signifies your application’s desire to be notified when iOS determines the user has interacted with a region bearing a particular UUID. Replacing our last comment up above with the following should do the trick:

// receive enter & exit notifications
[manager startMonitoringForRegion:region];

It is important to understand what we’ve done by requesting the monitoring of a region. We will now receive delegate messages when the user enters and exits our iBeacon region, as well as when something goes wrong. What won’t happen yet, though, is any actual interacting with the iBeacons. We have no way of knowing what their major and minor numbers are! The only thing we can now prove is a user’s presence in a region.

Finding iBeacons in a Region

In order to find the specific iBeacons nearby, we need to do what is known as ranging. When we range for iBeacons, iOS will tell us all about the ones it can see. Ranging is not cheap, however. Whilst Bluetooth Low Energy consumes remarkably little power, the act of ranging for iBeacons occurs at a frequency of 1 Hz, or about once per second. What this means is that we should be very judicious about beginning ranging, and only range as long as we need to.

We won’t find any iBeacons unless the user is in a region, so there isn’t much point in ranging otherwise. There are two perfect delegate methods we can hook into to start and stop the ranging process:

/* entered */
- (void)locationManager:(CLLocationManager *)manager
         didEnterRegion:(CLRegion *)region
    [manager startRangingBeaconsInRegion:(CLBeaconRegion *)region];

/* exited */
- (void)locationManager:(CLLocationManager *)manager
          didExitRegion:(CLRegion *)region
    [manager stopRangingBeaconsInRegion:(CLBeaconRegion *)region];

Now, when a user walks into one of our regions, we can begin searching for some iBeacons! Once iOS finds one, it’ll let us know, quite promptly, via another delegate method:

/* we found some iBeacons! */
- (void)locationManager:(CLLocationManager *)manager 
        didRangeBeacons:(NSArray *)beacons 
               inRegion:(CLBeaconRegion *)region
    NSLog(@"Ranged: %lu iBeacons!", (unsigned long)beacons.count);

Now, we have all of the iBeacons we can see, within our region, and can operate on them as we see fit. The one last thing we may want to do is stop ranging after we get the first batch of iBeacons. The logic behind this being, if a user enters your iBeacon’s region, and stays there for, say, a work day, that’s going to be 8hr * 60m * 60s (1 Hz) = 28,800 delegate messages! That’s.. pretty excessive. Then again, if a user is at your museum, and moving amongst the exhibits, which are denoted via minor number, and you’d like to do different things in front of different displays, you’ll have to monitor more frequently, making some sort of a cool down implementation more enticing.

We’ll assume that just finding the first iBeacon is sufficient, and update our method to be the following:

/* we found some iBeacons! */
- (void)locationManager:(CLLocationManager *)manager 
        didRangeBeacons:(NSArray *)beacons 
               inRegion:(CLBeaconRegion *)region
    NSLog(@"Ranged: %lu iBeacons!", (unsigned long)beacons.count);

    // any beacon will do
    CLBeacon *aBeacon = [beacons firstObject];

    // what UUID, major, and minor, as well as how far away the iBeacon is
    NSLog(@"Ranged: %@ | %@-%@ @", aBeacon.proximityUUID.UUIDString, 

    // be resonsible, respect the battery
    [manager stopRangingBeaconsInRegion:region];

That’s much better. Now, we get and can operate on an iBeacon, then request that ranging stop. We are still monitoring the region, so if the user exits then reenters it, we will get another opportunity to query the iBeacons.


One limitation iOS has, versus OS X and Android, is the inability to listen for iBeacon regions indiscriminately. The application must explicitly request monitoring for each and every UUID it is interested in hearing about. This is no doubt better for the user’s battery, but isn’t really spelled out clearly in the docs. It also makes for difficulties when trying to get a sanity check on what your iBeacons are actually reporting themselves as.

So, as a supplement to this blog post, and to your development efforts, I’ve written a small little iOS application that will allow your iPhone to define iBeacons it would like to be notified about, as well as a table of diagnostic data when it finds the iBeacons.

Find it here on BitBucket!

Wow, iBeacons Rock!

We agree! iBeacons make it effortless to interact with your users in a very granular and personal manner. The ability to augment their experiences, be it via time-based coupons, museum exhibit enhancements, or whatever else you can dream up is just plain cool, and phenomenal for business.

Leave a Comment


Wow, Josh seems to know what he’s talking about, very impressed

Reply to comment

The iBeacon technology seems highly promising and I am excited to try it. I am blind and live in the Lakeview neighborhood on the north side of Chicago. An iPhone application has just been released that can direct blind people to these beacons in indoor spaces. Could you identify some public installations of iBeacons so I could try the technology? It could offer a leap in independence for blind people.

Reply to comment

Kelly, our apologies for such a tardy reply! What’s the name of the iPhone app that was released? We did some asking around when you first commented, but did not get a definitive answer. We reached out to an experienced iBeacons developer and they said there’s no published list or map of iBeacons, either by government or private enterprises. Some companies like this one might have private lists available, but they’re usually for purchase by developers, not consumers/ users. Ultimately, you’re right, the technology is very promising on a number of levels and for a number of uses, including as accessibility tools. You might reach out the Chicago arm of the ADA Legacy project. They’re celebrating 25 years of the Americans with Disabilities Act, and they’re partnering with organizations for different events and advocacy in general. They might have some answers. Good luck, and we’ll let you know if we find a better answer!


The iPhone application I mentioned is called Blind Square, which was updated to version 3.0. The app directs blind people to the beacons by triangulating multiple beacon signals and using clock face orientation. The app delivers unique sounds through stereo headphones so the blind end user can have spatial orientation of the beacon in relation to his body and direction of travel through the stereo soundscape. Blind Square is the most widely used GPS navigation app for the blind in the world. The program is available in 25 languages and is used by tens of thousands of blind people in scores of countries.

iBeacons likely will offer a leap in independence for blind people. This is because the most independent and capable blind travelers have difficulty navigating unstructured indoor spaces. Few landmarks and cues in these spaces can be identified with a white cane. iBeacons
offer the possibility of delivering these landmarks and cues to the blind iPhone user.

I will follow up with the company you mentioned. It seems some national stores have installed some iBeacons. Apple stores supposedly have them but they did not work when a blind end user tried to access the network at a store in California. This was with another app though. Macy’s has them in all stores, but it seems that a specific app must be used and the user only receives notifications about offers. Apparently, other apps can’t access the beacons. McDonalds also has installed beacons, which I will investigate. The stores are small enough that good directions would likely help more than iBeacons.

I am already in frequent contact with the leaders of the ADA anniversary celebration. The effort is a tribute to the amazing increase of accessibility created through the Americans with Disabilities Act. This included my leadership with talking ATMs and voting machine accessibility. iBeacons represent the next frontier of accessibility where public iBeacon networks and apps for the blind could integrate technology for a new level of independence.

Reply to comment