Recently, I presented to Wellington CocoaHeads about how we experimented using iBeacons to execute hyper-personalized messaging that can target any user characteristic that’s relevant to an app. Through trial and error in the process of creating our test app, I learned some tips for mastering iBeacon that developers may find useful.

Important properties

Apple iBeacon properties

Regular iBeacon devices have three attributes – a UUID, Major and Minor. Apple recommends using one UUID for all your beacons, and differentiating locations hierarchically with major and minor versions. During our explorations, we found that the easiest way to determine a unique value for each beacon is to use a combination of the three attributes.

For our demo, we continued the use case of a retail chain with a beacon placed near the entrance of each store, and three additional beacons in different product aisles. Since the UUID and major are the same for one store location, the minor number becomes the point of difference at the store level. And, minor numbers for product aisle beacons are the same in every store – so the combination of UUID, Major and Minor attributes becomes necessary to define each beacon as a unique device.

Takeaway: Use a combination of UUID, Major and Minor attributes to give each beacon a unique identifier.

Attenuation

Attenuation was a big factor during our tests, as we frequently experienced large jumps when displaying the distance reading between the beacon and phone. Attenuation is caused by people, walls, desks, plants and anything in the line of sight of the beacon – which, is a problem for use cases in the real world. To alleviate the appearance of signal disruption, we displayed less precise but still accurate readings of distance on screen to the user (for example, rounding to the nearest foot rather than inch), and used more powerful beacons.

Takeaway: Expect attenuation in a real world environment, and compensate with less precise readings of distance, moving averages or simply report the proximity instead.

Background Processing

For the best performance, we used Core Location to find iBeacons while the app was in the background. From there, we attempted to set Custom Attributes in the app. However, because the background code must be asynchronous and single threaded, we needed to make some code changes for these to work. Since our SDK takes advantage of asynchronous processing on multiple threads, we quickly released an update that included synchronous, single threaded alternatives of the methods relating to Custom Attributes so you can set these in the background.

Takeaway: Avoid complicated code in the background of your app; trying to do too much will negatively impact your users’ battery life. Don’t forget you are limited to one thread.

iBeacon Opportunities

With the addition of synchronous methods, our SDK is fully compatible with iBeacon and ensures that your app reliably communicates to us that it’s interacting with a nearby beacon. iBeacons, especially when paired with advanced targeting by user behavior, offer incredible opportunities to create exciting user experiences. Make sure to check out our latest post on iBeacon marketing best practices.