Yahuui Blog: Software : Industry voice: 6 ways beacon app development is different

Sunday, July 6, 2014

Software : Industry voice: 6 ways beacon app development is different

Industry voice: 6 ways beacon app development is different

Posted:

Even the most experienced app developer will run into challenges that are unique to building a beacon app. These are the six challenges you will face:

1. Balancing UX and privacy in the feature set

Beacon apps approximate a user's physical distance from a beacon so you can link information about the real world context of the beacon with specific context of the user. When building your beacon app, you need to carefully weigh which elements will improve the user's experience without overwhelming them as well as factoring in user privacy. If you get the balance right, you'll be able to selectively 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).

2. Permission to activate Bluetooth and location services

For beacon apps to perform, not only does the mobile device have to support beacons but also the user has to enable Bluetooth and location services. I've found that it's best to wait until the last possible moment to ask for these permissions. This way, you have an opportunity to prove your app's value instead of blasting users before they've even tried the app or are close to a beacon.

3. Variable signals

Beacon apps are dealing with external radios that transmit signals and therefore can be messy. The app has to best guess the beacon'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 spectrum is in the same spectrum band as Wi-Fi, which can interfere with the signal. Furthermore, signal quality varies wildly among beacon hardware manufacturers. Lastly, beacon signals are affected by temperature, device power, and polling intervals, which may vary from broadcast to broadcast. In short, the app has to be designed to make choices based on the variable information received.

4. Workarounds for triangulation & tracking

Two-way communication between a beacon and an app is not possible with beacons 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 beacon 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.

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.

5. The business logic imperative

Given all the variables, business logic scripts are a must-have. For example, the app has to collect data such as the beacon UUID, major and minor numbers, and location. When the app encounters a beacon, a business logic script then relays a list of all the users nearby. This script filters the data for privacy and interprets 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 the beacon ranging. 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, perform statistical analysis and draw conclusions.

6. The final challenge – the App Store review

Based on my experience, you should:

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

What helped me most when building our beacon app for the recent GlueCon conference were pre-built backend tools plus client library extensions. They helped to "glue" together the context between the real-world locations of beacons, users to beacons and users to users.