At first glance, building an iOS app using Apple’s iBeacon API seems fairly straightforward. The API only consists of a few classes and methods and a ‘beacon’ isn’t actually a terribly complicated thing: in most cases (unless it’s paired with other technology) it simply transmits a small packet of data and lets your app do the rest.
But Apple being Apple the lack of clear documentation can be frustrating. It isn’t the code that’s complicated, it’s deciding what to do with it and how to interpret it that can cause confusion.
Here are five decision points I’ve wrestled with while working with our development team:
1. How Should I Configure My Beacons?
In a future post, I’ll cover off some basic stuff about choosing a type of beacon. The simple answer is that it depends: your use case will drive your decision, and the ability to manage the beacons and combine them with other technologies matters more than the actual specification of the beacon itself.
But once you have a beacon – whether it’s a phone, a virtual beacon or a physical beacon you attach to a wall, you’ll need to decide how to set up its major/minor values, UUID and power settings:
- UUID is usually reserved for a ‘fleet’ of beacons. Some beacons, such as Estimote, don’t currently let you change the UUID although they will once they release their cloud ‘fleet management service’
- Major/minor are groupings within that fleet. Maybe you have five stores: UUID can be for your chain of stores, major for an individual store, and minor for a department within a store
- The power setting of your beacon is key tweaking the range at which your beacon can be ‘seen’. Higher power means higher battery drain, however, so you’ll need to consider the long-term trade-offs. Out of the box, most beacons will work 18 months to 2 years without a battery change.
The following explanation might help understand power, accuracy and precision and refers to Estimote beacons but the general rules equally apply to other device types:
Virtual Beacon created with CoreLocation or our SDK broadcasts a very strong signal with high advertising frequency. That’s why the accuracy can be much more precise. As you probably know, every iBeacon broadcasts a measured power value in its advertising packet. This is the RSSI value which is achieved when the device is about one meter away from iPhone. The calibration procedure presented in AirLocate measures the device signal strength and returns the suggested measured power value.
We measured the signal strength for all PowerLevel values that can be set for our beacons so that the beacon changes that broadcasted measured power value if the PowerLevel is changed. If the PowerLevel is set to the lowest ESTBeaconPowerLevel1 the accuracy will begin to lose precision very fast, if the power is set to ESTBeaconPowerLevel8 you will notice that iPhone is able to hear the device from higher distance and the accuracy gains more precision.
To improve accuracy precision you can also increase advertising frequency of our Beacons using our SDK. Remember that changing it may have a negative effect on beacon’s battery life.
2. How Do I “Wake Up” The Users App?
You can’t ‘wake up’ an app which is closed. Unless your app is on in the background, local notifications won’t work with iBeacons. But if your user has opened the app and then hit the ‘home button’ to put it into the background, the app can listen for beacon regions.
You can also trigger your app to ‘do stuff’ using geolocation – in essence handing off scanning from GPS to the beacons once your app enters the zone.
But setting up and testing Region Monitoring can be a pain – especially if you’re finding you need to hard code it into your app or need to change regions once you’ve submitted to the app store.
Radius Network has a handy Proximity Kit that lets you set up regions and beacons “in the cloud”, drop a snippet into your app, and then adjust your beacons and regions from their control panel.
The basic logic is as follows:
- Use CLLocation to determine when your user has entered a ‘circular’ zone. Note that there can be a delay in the notice being sent to the user, so you’ll want to adjust your user experience to allow time from entry to notice receipt. Apple clarifies:
“In iOS, regions associated with your app are tracked at all times, including when your app is not running. If a region boundary is crossed while an app is not running, that app is relaunched into the background to handle the event. Similarly, if the app is suspended when the event occurs, it is woken up and given a short amount of time (around 10 seconds) to handle the event.”
- Possibly send a LocalNotification message based on region entry. One reason to do so is to pull your app into the foreground if the entry into the region is close to entry into a beacon range. There’s a significant difference in responsiveness to beacons between the app being in the background and foreground.
- Now you’re ready to find the specific beacons in the ‘zone’ and send messages or content based on proximity.
3. Deciding How to Calibrate Beacon-Triggered Changes Based On PRECISION
So, you’ve used Region Monitoring to make your app aware that it’s entered an area with beacons in it. Now what? The first challenge is understanding the range of trigger points or ‘precision’ of proximity to a beacon.
At the simplest level, the further you are from a beacon the ‘fuzzier’ the zone edges will be. Adding to the challenge, 10 identical beacons will have 10 different results: not just because you put them in 10 different places, but at 10 different times of the day!
The reason is interference. In one location, interference might be high and so the zone edges can be radically different from a more open space with less interference. Time of day will have you seeing different results – more signals in the air, more interference.
Your use case needs to account for this fuzziness. The further you are from a beacon, the more the variance in detecting the beacon, compounded with still more variance at times of the day when there’s more signal interference. The closer you are, the more accurate.
The amount of precision you need will influence the number of beacons you put in and the role you assign to them: “hey, welcome to the store!” vs. “buy this bag of chips”.
Where this gets really complicated is when your app ‘hears’ multiple beacons. How it decides which beacon is closest isn’t as simple as it sounds, and you might find your app toggling between different beacons. How you calibrate and place your beacons in a physical environment isn’t, in fact, as simple as it might sound – depending on how your app has been coded to decide which beacon to listen to.
4. Deciding How to Calibrate Beacon-Triggered Changes Based on REGION, RSSI, and ACCURACY
Further complicating things, your app will “lag”. And here’s where we get into the magical mystery of how Apple is doing calculations behind the scenes.
The easiest way to trigger app changes is to use CLProximity, which puts your app either Unknown/Immediate/Near or Far from the beacon. Apple doesn’t explain the math behind these calculations and so you’re reliant on a sort of rolling range. Apple clarifies that this value is “heavily filtered” and recommends that unless you’re a power user you avoid the RSSI and accuracy data that a beacon broadcasts:
“RSSI and proximity estimate are not one-to-one. The proximity estimate is a heavily filtered value intended to capture typical user behavior and use cases. The other values are available for “power users” who are willing to spend time experimenting and curating a specific experience for users.”
So, while you can use CLProximity, those smart coders out there will be playing with all the more granular readings to set up event triggers in their apps. What’s unclear to me is whether the SDKs that the beacon providers have released are using their own calculations for Proximity.
5. Deciding How to Calibrate Beacon-Triggered Changes Based on DELAY
Finally, there will be delays in an event being triggered and these delays will fluctuate. Not only do they fluctuate, but they fluctuate under nearly equal conditions in ways that seem to be related to the way that iOS handles polling frequency, app status and background tasks.
They can be insignificant or they can be very noticeable. Local Notifications, for example, can trigger in seconds if your app is in the foreground, or they can appear a minute later in some cases. Even waving your phone back and forth near a beacon can result in a range of responses that vary from less than a second to a second or two.
It’s All Experience Design
Maybe the above makes it sound like beacons are these fuzzy unreliable beasts. I guess it depends how you look at it. But what we’ve found is that by exploring the trade-offs and understanding of how Bluetooth LE works in the “real world” we’re getting all kinds of insights into how to create compelling user experiences.
Small tweaks to how an app appears, how it signals upcoming events to users, how you set expectations through the UI layer of your app: all of these things are helping us create richer strategies and approaches.
While this stuff isn’t easy, it’s also awakening us, ironically, to the richer possibilities of iBeacons by understanding that they’re not something you just pop on a wall and walk away from. They need the smart coders and the even smarter experience engineers to help create meaningful iBeacon powered applications.
Anything to add? I’m not a coder – just trying to interpret what I’ve learned from others who know a lot more about this stuff than I do! So drop me an e-mail or comment below – your input is deeply appreciated.
Be the Beacon!