Building an iBeacon-based app

I spent a big chunk of my free time in the last couple of months to build an iOS app. The app’s primary feature is to connect with people who are in your close (close as in Bluetooth) range. Here’s what I’ve learned in the process.

Handling permissions – your users will see lots of dialogs

Running anything in the background in iOS is painful. From Apple’s point of view this is perfectly reasonable – they don’t want you to drain their devices’ precious battery. On the other hand the UX is terrible. You’ll only get one shot to convince your users to give you the desired permission. If they don’t do it then comes the “leave the app and change the settings” scenario. Instant churn.

The Location Services background permission is a special case. Apple will constantly ask the user in random intervals if they are aware that your app does location scans in the background. This can quickly lead your users to disable it as it was some kind of malware.

Then there are some badly worded system dialogs – my favorite is the “Turn on Bluetooth” dialog which has two buttons: OK and Settings. You’d assume that the OK button would turn on Bluetooth but it just closes the dialog. It’s really nice since users generally don’t read these at all, just bluntly hit OK and expect the problem to go away.

The background settings are brittle at best. There’s an app level permission, and there’s a permission for the whole system (parental lock excluded). It again makes sense from the user’s side, but from the app’s side it’s disastrous. The API calls will just return that there’s no required permission to run, but they won’t tell you why. It’s quite hard to guide the user through the problem if you don’t know the cause.

BLE is special

In a bad way. First there’s no way to tell if the device Bluetooth is turned off, or is not supported at all (aka iPhone 4). Now I lied, you can deduce this with checking various constants, but if you’d like to do this cleanly using the API you’re doomed.

Then there’s the plist fun when you need to add the keys to support background Bluetooth running. You can also have a lot of fun with events not firing, or firing with a huge (40 secs) of latency. In a real time app like mine, this is a huge deal.

Broadcasting iBeacons in the background – confusion overload

The short answer is that it’s impossible. You will only be able to broadcast iBeacons when your app is in the foreground. The problem is that there are tons of resources (mostly stackoverflow users in despair) who claim otherwise or offer creative ways around the problem. But nothing works. What works is a UX which rewards the user for opening and engaging with the app. Forget everything else.

Background Bluetooth scanning – even more confusion

Ranging or geofencing (region entering and leaving)? What constitutes a region? What can I do in the background?

I was really confused at first. Region entering can run in the background, but with a limited set of regions (I remember 20 for the whole device). Ranging cannot run when you’re in the background. The problem is when you use iBeacons you’d like to identify them (major/minor anyone?). Region entering won’t do this for you, you’ll need ranging.

But a little creativity goes a long way. Entering a region will wake up your app and you’ll have 5 seconds to do what you need. Now you can use these 5 seconds for ranging, since you’re not in the background anymore. Problem solved.

So what’s the conclusion?

If I were to start again this app I’d do it on Android. I finished it because the emotional investment was huge. On iOS you’d get seriously hindered functionality when you try to be creative with iBeacons. They seem to be a perfect fit for indoor navigation but when you try to do something different you’d hit into way too much barriers.

Oh, the app is waiting for review right now. I’m very interested to see if Apple approves it. I’ll post about it when it’s done.

Advertisements

How I failed to pivot because of the ‘coolness factor’

iBeacons? Build something with them!

A couple of months ago I was browsing the news and stumbled upon Apple’s iBeacon technology. After some digging on the internet I figured I would like to build something awesome on it. I started brainstorming with my best friend and all-time business partner on the potential and what we could do. Initially I had a hard time trying to persuade him thinking out of the box. Apple has set some boundaries for this technology in the way they pivot it. They proposed indoor navigation or showing some price tags. However in two or three quick iterations we had the idea ready: use it as a foundation of a new dating app. Ironically we failed because I was unable to think out of the box – and didn’t see the need to the pivot.

The idea – let’s revolutionise dating!

The app’s workflow was pretty simple: you fill a form about yourself and your dating preferences. The app immediately starts to publish this information on Bluetooth Low Energy. In the same time it starts a subscriber and polls for other people’s broadcast. If someone is within range and there’s a match you and the potential partner would receive a push notification, asking whether or not you like the other party. You’d be able to show interest in the other party by hitting a nice green “Interested” button. Alternatively you could politely turn them down by tapping on the red “Not interested” one. If both parties are interested they are notified and they can begin getting to know each other. Due to the very nature of BLE and iBeacons, these people would be in close proximity, so this would be pretty easy.

Why would anyone use this thing?

Now what is the purpose of this? Why would I fiddle with my smartphone instead of just walking up the other person? In one word, what is the pitch? Well, for starters the sad thing is that everybody is always hooked on their phone. I’m not in the position to judge this, but sometimes it’s pretty hard to deal with it. People are perceiving the world through their smartphone screens, and in the end, more aspects of “real” life would march to that screen. The other point is that everybody has insecurities. It takes courage to walk up to another person and initiate a conversation, particularly if you have romantic intentions. We’d just facilitate the meeting process by providing a painless (or at least, less painful) way to deal with rejection.

The technical problems

I implied in the beginning that we eventually failed to build this app. What was the problem? In short I was too focused to build something on iBeacons and BLE that I built the whole idea around it. And Apple has some technical limitations in place which made it impossible to deliver the product using this technology. In a few words, your app would have to run in the foreground, and the other party’s app too. This of course is not a viable scenario for this kind of app.

And failing to overcome them

I was so blinded by the cool new technology factor that when it turned out we cannot do this I didn’t start to pivot, despite all the startup literature I read. And we were pretty close, with just a little pivoting, we could have delivered a working product. The proof is ntice, a Hungarian startup with the exact same idea.

Conclusion

So what’s the conclusion? It’s pretty clear from the outside and common sense dictates that you need to pivot or persevere (or, worst case, let it go). This scenario was clearly a pivot one, the solution would be to ditch iBeacon and work on some check-in based stuff like Foursquare. Or ditch Apple and go with Android. Or something else that never occurred to me. But never ever let the opportunity of using a cool technology cloud your judgement.