The 6 challenges of building an iBeacon app

Using iBeacon, Apple’s low-powered method of pushing contextual notifications to iPhones in stores, introduces a bunch of messy moving parts, I discovered recently while building an app for the Gluecon conference.

Despite being an experienced iOS developer, I faced the following six distinct challenges.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1490257,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"mobile,","session":"A"}']

Choosing the feature set

Enabling your app for iBeacon lets you approximate a user’s physical distance from a broadcasting beacon and then link information about the real world context of the beacon with specific context of the user.

This allows you to push information to the user, for example, based on the time (a limited time coupon), user preference (modernist vs. impressionist paintings in a museum), or current conditions (less crowded checkout lines). So when building your iBeacon app, you need to carefully weigh which elements improve the user’s experience without overwhelming them. At the same time, you need to consider what protects user privacy and doesn’t cripple the app if the beacon isn’t in range.

[We’ll be exploring how new mobile technologies like iBeacon can help to drive purchases in stores at Mobilebeat 2014 in San Francisco on July 8-9. Grab your tickets now!]

Figuring out the permission matrix

To perform, iBeacon apps need to check several states. First, does the device support iBeacon? Second, has the user enabled Bluetooth and location services, thereby providing permission for the app to access the device’s location?

In some cases, it’s best to wait until the last possible moment to ask for these permissions, instead of blasting users before they’ve even tried the app or are close to an iBeacon. It’s also important to proactively offer information explaining the value of the app and how user data is protected.

Dealing with messy signals

iBeacon apps are dealing with external radios that transmit signals and therefore can be messy. This device has to best guess the iBeacon’s distance, which is challenging because radio waves bounce around a physical location and are affected by the presence of users. Plus, the Bluetooth LE (low-energy) spectrum is in the same spectrum band as Wi-Fi, which can interfere with the signal.

Furthermore, signal quality varies wildly among iBeacon hardware manufacturers. Lastly, beacon signals are affected by temperature, device power, and polling intervals, which may vary from broadcast to broadcast. In short, signal accuracy is highly variable which means the app has to be designed to make choices based on the variable information received.

Triangulation & tracking

Two-way communication between an iBeacon and an app is not possible since they are one-way radios: they don’t know about the client devices receiving their broadcasts. There are two workarounds for this. First, an advanced iBeacon could theoretically open a second channel to communicate with the mobile device and then transmit that data back to a server using a persistent network connection. However, this functionality is not part of the iBeacon specification and it would be a significant battery drain.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":1490257,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"mobile,","session":"A"}']

The easier way is to fake it by making the app do the work. By connecting the app to a backend, it can update a record to register the user’s real-time presence  and then personalize the app or real world experience in real-time.

The server piece

Given all the variables encountered by an iBeacon app, business logic scripts are a must-have. For example, your app needs to collect data about the beacons such as its UUID, major and minor numbers, and location on a floor plan.

When the app encounters a beacon, it needs to access the business logic script to get a list of all the users at a beacon. This script filters the data for privacy and tries to interpret what “at the beacon” means — which is tricky, given that updates at events may not be recorded in real-time or the device might drop out of the beacon’s range.

One solution is to use a time-based heuristic to guess if the user is reasonably still there. Other business logic scripts can be used to observe trends (such as most popular booth at a trade show), perform statistical analysis and draw conclusions.

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":1490257,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"mobile,","session":"A"}']

 Navigating the App Store review process

Your final challenge! Here’s what I learned:

• Clearly explain how the app works and its value – both in the public description and in the review notes. A demo video to explain the app function helps.
• Provide a demo account and some beacon UUIDs in the review notes.
• Include a battery use disclaimer in your description.

Building a beacon app is very different from building other types of apps. What helped me overcome these challenges and expedite development was using pre-built tools and client library extensions that provided the glue, linking iBeacons to their real-world location, users to beacons, and users to users.

Mike Katz is the principal software engineer at Kinvey.