Open

iBeacons: Lessons Learned

We’ve been experimenting with iBeacons a lot at Mutual Mobile. We’ve done a few prototype projects (some of which found their way into client work), had endless conversations with iOS devs in and outside of our organization, and even threw a Hackthon centered around the technology, which allowed us to explore some of our more outré ideas.

We’ve been experimenting with iBeacons a lot at Mutual Mobile. We’ve done a few prototype projects (some of which found their way into client work), had endless conversations with iOS devs in and outside of our organization, and even threw a Hackthon centered around the technology, which allowed us to explore some of our more outré ideas.

Since there are already plenty of great articles out there on how iBeacons work and what they’re suited for, I thought it might be useful to recount a few of the lessons we’ve learned while tinkering with iBeacons.

What you can do when your App is in the Background

There’s been a lot of talk about apps using iBeacons in the background ever since the introduction of iOS 7, but some of it is overblown. One of the only things your app can do when it’s installed, but not in the foreground, is find out when your device sees or stops seeing a particular iBeacon transmitter. Anything beyond that is a myth, as far as iBeacons are concerned.

When you move in range of a beacon for which your app has registered to receive notifications, the CLLocationManager will call the didEnterRegion method on the delegate object you’ve designated in your app. When you move out of the beacon’s range, it calls didExitRegion. In either case, your app gets fired up in the background for a few seconds to respond. You can call a web service, post a local notification, or just log the event for later action. However, you can’t reliably tell how far away you are from the transmitter or continue to monitor changes in signal strength over time.

But wait! If I can’t monitor signal strength, how do I make my app respond in the background only when someone gets really close to my transmitter? The trick here is a simple one: dial down the power on your transmitter so that other devices don’t see the signal until they’re close. The bad news is, not all vendors support this ability in their beacon hardware (Apple’s API that lets you use an iOS device as a beacon doesn’t either).

Some apps do appear to do iBeacon ranging when in the background—like getting updates on the strength of the beacon’s signal—even though Apple’s API doesn’t officially support it. Justin Youens speculates that these apps may be firing up location monitoring to keep the app active; a potentially viable approach, but not one that’s particularly easy on the device’s battery.

Dan Murrell also points out that if you have background app modes turned on, interacting with your device—even just to check the time on the lock screen—will also allow your app to range for a few seconds if you’re already inside a beacon region. This behavior isn’t documented, so it may not continue to work indefinitely, but it could be useful as long as you’re not building a business on it.

What you can do when your App is in the Foreground

Continuous Ranging

There are two ways to get ranging information from Apple’s API:

First, there’s identifying proximity through the CLLocationManager’s didRangeBeacons delegate method, which receives an array of found beacons. Each beacon has a proximity property that lets you know that it is “Near”, “Far”, or “Immediate” to the transmitter.

Second, iBeacons have a rssi property and an accuracy property that can be used to extract more granular information about the signal strength the device sees. When your app is in the foreground, you can continue to get updates to this ranging information and respond to it as long as you like.

Transmitting

In addition to ranging when your device is in the foreground, it can operate as an iBeacon itself. This can be useful for things like Point-of-Sale (POS) systems in a store or telling you where your opponents are hiding during a modern game of Hide-and-Seek. After setting up the necessary data structures, a quick call to CBPeripheralManager’s startTransmitting method will get that going.

It’s important to remember, however, that this only works when your app is in the foreground, which makes it of limited use for static installations unless you’re committed to having a single app always running. It’s potentially useful for POS systems, but not so much for the family iPad in the kitchen.

What can’t you do?

Actually figure out distances

Contrary to what you might assume, it’s really hard to use iBeacons to get a good sense of your actual geographic location. You’ll note that none of Apple’s APIs really give you any concrete distance information. Even the accuracy property—which is the only thing calibrated in meters—warns in the docs: “Do not use it to identify a precise location for the beacon.”

There’s a good reason for this: low power radio signals like Bluetooth (especially Bluetooth low energy), operating in an unregulated band like 2.4GHz, are super susceptible to interference. Merely standing with your body between the iBeacon and your phone can cause a precipitous drop-off in the signal. Since the highly-variable signal strength is all an iOS device has to go on, there’s no way to accurately determine the distance between your device and a beacon.

Scan for iBeacons on iOS

iBeacons use Bluetooth LE advertising packets to do their magic. Because Core Bluetooth provides a comprehensive suite of Bluetooth LE functionality, it would be reasonable to think that you’d be able to scan for nearby iBeacons. This would be true, except for the fact that Apple apparently filters out these results deliberately on iOS: Core Bluetooth will return any advertising packets from nearby BLE devices except for those that include the iBeacon prefix.

Ironically, because Google doesn’t officially support iBeacons, you can scan for them using an Android device. Bluetooth scanning software is also available for all of the popular desktop operating systems (OS X included).

Large Scale Deployments

Because Core Location only allows you to register 20 regions at a time, you might think that you could only have your device look for 20 beacons. Fortunately, Apple was forward-thinking enough to provide an approach that can provide for huge deployments. In fact, if you have a chain of 20,000 coffee shops and want to trigger your app whenever a customer enters one of the locations, beacons are a far better approach than traditional geofencing.

The trick here is while you need to know the UUID of the beacon you’re looking for, you don’t need to know the major or minor versions. If you deploy a beacon in every one of your stores, all you have to do is make sure all of the beacons have the same UUID and different major/minor numbers. You can monitor a single region with the common UUID, and the individual regions will tell you their major/minor numbers, allowing you to tell which store your customer has just entered. Since the major and minor numbers are both unsigned 16 bit integers, you can detect more than 4.2 billion different locations using a single Core Location region, which will give your coffee shop chain plenty of room to expand.

Note that just because you deploy a bunch of iBeacons, it doesn’t mean that other apps will be able to take advantage of them indiscriminately. The 20 region limit still means that apps will have to specifically subscribe to notifications for a given UUID, making it impractical for a single app to watch for any random beacons it comes across. These restrictions make it clear that Apple intends for specific beacons to be matched to specific apps.

But how does [VENDOR] do [COOL FEATURE]?

The iBeacon spec is fairly focused in what it can do. However, since iBeacons are Bluetooth LE devices by definition, there’s nothing to prevent a vendor from providing additional functionality using the rest of the BLE stack. For example, many beacon vendors provide management software that lets you adjust the UUID and major/minor numbers that a beacon is broadcasting.

Security Concerns

iBeacons are a transmit-only technology. They’re like a lighthouse, informing passing ships of their presence, but not able to receive any information back. Because of their one-way nature, security risks are generally small.

If you’re doing a deployment, however, you should be aware of any remote management features your vendor’s beacons provide. If they provide remote management software with a default password, you’ll want to be sure you change it so that any passerby with the appropriate management software won’t be able to change your beacons settings. And of course you’ll want to give some thought to physical security as well so that your beacon hardware isn’t walking off with a sticky-fingered visitor.

In addition, if malicious parties decide that they’d like to interfere with your iBeacon deployment, they could theoretically set up a beacon that pretends to be yours just by knowing your UUID (and possibly major/minor numbers, depending on what your app is listening for). As a general rule of thumb, you should never take any nonreversible or security-sensitive actions based solely on the presence of an iBeacon.

David Barnard points out that online catalogs of known UUIDs have started popping up online, making spoofing easy without even having to use a Bluetooth scanner. Thus, it would be wise to verify even a location-dependent coupon in some way other than phone proximity.

iBeacons may also be subject to battery failure, radio interference, or other hardware issues, so if you’re designing a solution around them, be sure to include alternate backup methods to activate any critical functionality.

Final Thoughts

Apple’s implementation of iBeacons has continued to improve with each iOS update since its release. Additionally, Passbook also supports iBeacon-based passes. If you’re working on Passbook-enabled projects, it’s worth exploring the technology in that context as well.

Because beacons aren’t tied to a specific geographical location, they also open the door to an interesting range of use cases with mobile transmitters—alerts when a bus comes near, finding your lost keys in the sofa cushions, etc.

While iBeacons are not the revolutionary panacea the tech press might have you believe, and much of what they provide could reasonably be done with Bluetooth LE already, the background monitoring, standardization, and easy-to-use API make them a useful addition to the mobile developer’s toolkit.

Since there are already plenty of great articles out there on how iBeacons work and what they’re suited for, I thought it might be useful to recount a few of the lessons we’ve learned while tinkering with iBeacons.

What you can do when your App is in the Background

There’s been a lot of talk about apps using iBeacons in the background ever since the introduction of iOS 7, but some of it is overblown. One of the only things your app can do when it’s installed, but not in the foreground, is find out when your device sees or stops seeing a particular iBeacon transmitter. Anything beyond that is a myth, as far as iBeacons are concerned.

When you move in range of a beacon for which your app has registered to receive notifications, the CLLocationManager will call the didEnterRegion method on the delegate object you’ve designated in your app. When you move out of the beacon’s range, it calls didExitRegion. In either case, your app gets fired up in the background for a few seconds to respond. You can call a web service, post a local notification, or just log the event for later action. However, you can’t reliably tell how far away you are from the transmitter or continue to monitor changes in signal strength over time.

But wait! If I can’t monitor signal strength, how do I make my app respond in the background only when someone gets really close to my transmitter? The trick here is a simple one: dial down the power on your transmitter so that other devices don’t see the signal until they’re close. The bad news is, not all vendors support this ability in their beacon hardware (Apple’s API that lets you use an iOS device as a beacon doesn’t either).

Some apps do appear to do iBeacon ranging when in the background—like getting updates on the strength of the beacon’s signal—even though Apple’s API doesn’t officially support it. Justin Youens speculates that these apps may be firing up location monitoring to keep the app active; a potentially viable approach, but not one that’s particularly easy on the device’s battery.

Dan Murrell also points out that if you have background app modes turned on, interacting with your device—even just to check the time on the lock screen—will also allow your app to range for a few seconds if you’re already inside a beacon region. This behavior isn’t documented, so it may not continue to work indefinitely, but it could be useful as long as you’re not building a business on it.

What you can do when your App is in the Foreground

Continuous Ranging

There are two ways to get ranging information from Apple’s API:

First, there’s identifying proximity through the CLLocationManager’s didRangeBeacons delegate method, which receives an array of found beacons. Each beacon has a proximity property that lets you know that it is “Near”, “Far”, or “Immediate” to the transmitter.

Second, iBeacons have a rssi property and an accuracy property that can be used to extract more granular information about the signal strength the device sees. When your app is in the foreground, you can continue to get updates to this ranging information and respond to it as long as you like.

Transmitting

In addition to ranging when your device is in the foreground, it can operate as an iBeacon itself. This can be useful for things like Point-of-Sale (POS) systems in a store or telling you where your opponents are hiding during a modern game of Hide-and-Seek. After setting up the necessary data structures, a quick call to CBPeripheralManager’s startTransmitting method will get that going.

It’s important to remember, however, that this only works when your app is in the foreground, which makes it of limited use for static installations unless you’re committed to having a single app always running. It’s potentially useful for POS systems, but not so much for the family iPad in the kitchen.

What can’t you do?

Actually figure out distances

Contrary to what you might assume, it’s really hard to use iBeacons to get a good sense of your actual geographic location. You’ll note that none of Apple’s APIs really give you any concrete distance information. Even the accuracy property—which is the only thing calibrated in meters—warns in the docs: “Do not use it to identify a precise location for the beacon.”

There’s a good reason for this: low power radio signals like Bluetooth (especially Bluetooth low energy), operating in an unregulated band like 2.4GHz, are super susceptible to interference. Merely standing with your body between the iBeacon and your phone can cause a precipitous drop-off in the signal. Since the highly-variable signal strength is all an iOS device has to go on, there’s no way to accurately determine the distance between your device and a beacon.

Scan for iBeacons on iOS

iBeacons use Bluetooth LE advertising packets to do their magic. Because Core Bluetooth provides a comprehensive suite of Bluetooth LE functionality, it would be reasonable to think that you’d be able to scan for nearby iBeacons. This would be true, except for the fact that Apple apparently filters out these results deliberately on iOS: Core Bluetooth will return any advertising packets from nearby BLE devices except for those that include the iBeacon prefix.

Ironically, because Google doesn’t officially support iBeacons, you can scan for them using an Android device. Bluetooth scanning software is also available for all of the popular desktop operating systems (OS X included).

Large Scale Deployments

Because Core Location only allows you to register 20 regions at a time, you might think that you could only have your device look for 20 beacons. Fortunately, Apple was forward-thinking enough to provide an approach that can provide for huge deployments. In fact, if you have a chain of 20,000 coffee shops and want to trigger your app whenever a customer enters one of the locations, beacons are a far better approach than traditional geofencing.

The trick here is while you need to know the UUID of the beacon you’re looking for, you don’t need to know the major or minor versions. If you deploy a beacon in every one of your stores, all you have to do is make sure all of the beacons have the same UUID and different major/minor numbers. You can monitor a single region with the common UUID, and the individual regions will tell you their major/minor numbers, allowing you to tell which store your customer has just entered. Since the major and minor numbers are both unsigned 16 bit integers, you can detect more than 4.2 billion different locations using a single Core Location region, which will give your coffee shop chain plenty of room to expand.

Note that just because you deploy a bunch of iBeacons, it doesn’t mean that other apps will be able to take advantage of them indiscriminately. The 20 region limit still means that apps will have to specifically subscribe to notifications for a given UUID, making it impractical for a single app to watch for any random beacons it comes across. These restrictions make it clear that Apple intends for specific beacons to be matched to specific apps.

But how does [VENDOR] do [COOL FEATURE]?

The iBeacon spec is fairly focused in what it can do. However, since iBeacons are Bluetooth LE devices by definition, there’s nothing to prevent a vendor from providing additional functionality using the rest of the BLE stack. For example, many beacon vendors provide management software that lets you adjust the UUID and major/minor numbers that a beacon is broadcasting.

Security Concerns

iBeacons are a transmit-only technology. They’re like a lighthouse, informing passing ships of their presence, but not able to receive any information back. Because of their one-way nature, security risks are generally small.

If you’re doing a deployment, however, you should be aware of any remote management features your vendor’s beacons provide. If they provide remote management software with a default password, you’ll want to be sure you change it so that any passerby with the appropriate management software won’t be able to change your beacons settings. And of course you’ll want to give some thought to physical security as well so that your beacon hardware isn’t walking off with a sticky-fingered visitor.

In addition, if malicious parties decide that they’d like to interfere with your iBeacon deployment, they could theoretically set up a beacon that pretends to be yours just by knowing your UUID (and possibly major/minor numbers, depending on what your app is listening for). As a general rule of thumb, you should never take any nonreversible or security-sensitive actions based solely on the presence of an iBeacon.

David Barnard points out that online catalogs of known UUIDs have started popping up online, making spoofing easy without even having to use a Bluetooth scanner. Thus, it would be wise to verify even a location-dependent coupon in some way other than phone proximity.

iBeacons may also be subject to battery failure, radio interference, or other hardware issues, so if you’re designing a solution around them, be sure to include alternate backup methods to activate any critical functionality.

Final Thoughts

Apple’s implementation of iBeacons has continued to improve with each iOS update since its release. Additionally, Passbook also supports iBeacon-based passes. If you’re working on Passbook-enabled projects, it’s worth exploring the technology in that context as well.

Because beacons aren’t tied to a specific geographical location, they also open the door to an interesting range of use cases with mobile transmitters—alerts when a bus comes near, finding your lost keys in the sofa cushions, etc.

While iBeacons are not the revolutionary panacea the tech press might have you believe, and much of what they provide could reasonably be done with Bluetooth LE already, the background monitoring, standardization, and easy-to-use API make them a useful addition to the mobile developer’s toolkit.

Stay-Up-To-Date

Keep in the loop with the latest in emerging technology and Mutual Mobile