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.