iBeacon programming is deceptively simple. But knowing what classes to use in your XCode project is just part of the challenge. Taking advantage of the extra ‘packets’ in Bluetooth, understanding how far a beacon ranges, and how to use advertising identifiers can challenge even the most experienced programmer.
In this guest post by Richard Bown of Xyglo BV, we find some unexpected insights into how beacons work and how developers can benefit from them.
Your Phone is a Beacon: Using App Pairing
I’ve been recently investigating the properties of iOS7 iBeacon development while working on my first iBeacon app – VoucherThing. While a lot of people are looking to implement bespoke hardware beacons or implement off-the-shelf solutions for retailers I was more interested in the software possibilities. I also know that I could turn my iPhone and iPad into an iBeacon so I saw that as the path of least resistance to iBeacon nirvana!
My starting point were some of the excellent example iBeacon app pairing projects. The concept of these are simple – download the example, build the apps from the projects in Xcode, send them down the wire to your test devices and then you can be up and running and testing ranging in no time at all. And immediately you’ll notice how the range of the iDevices can quickly get diminished in busy or crowded environments. You may have heard some bold claims for BLE and iBeacon but these are very dependent on surroundings.
Home on the Range
In the iOS code, iBeacons are set up in a similar manner to CoreBluetooth services except the service setup calls require a Major and Minor company identifier to be specified in both the sending (Peripheral) and the receiving (Central) device. These identifiers will fire off the appropriate delegates to match entering and leaving of iBeacon zones around the device. For anyone who’s built an iOS app before none of this will cause too much of an issue.
iBeacon ranging splits the world into four areas – Near, Mid, Far and Out Of Range. From my testing in the house and in office environments using an iPad Mini and an iPhone 4S the distances appear to stack up a little like this – although your mileage may most definitely vary!
Near – touching -> 20cms
Mid – 20cms > 5-10m
Far – 5-10m+
Out of range – 20-30m+
These figures vary per environment but they certainly fell a bit short of my initial expectations. In retrospect though and considering what iBeacon gives you I’ll take this is a starting point, and bear in mind that these ranges are only likely to improve and get probably get more accurate.
Wake Me Up
One of the great things about iBeacon is the ability to get apps to send user notifications on range boundary changes. When an iBeacon comes into range the iDevice owner can be notified with a message if they’ve enabled notifications and location services – for example they can be told to go and visit the retailer assuming you have that particular app installed.
This can be very useful when using pairs of apps – with VoucherThing there is a customer app and a merchant app. Both act as iBeacons and both can detect each other – this means we can implement a ‘radar’ type of user interface which tells the user of either how many customers or how many merchants are in the area, both apps also get notifications when customers or merchants come into view. Also due to the way that iBeacon is implemented in iOS7 notifications occur even when the app is backgrounded.
Never The Twain: Core Bluetooth
During experimentation with iBeacon I also wanted to try and transmit extra information (merchant logo and information) alongside my beacon. As far as I’m aware you can only transmit a few extra bytes of information along with iBeacon – not enough to transmit image data in any meaningful period of time. Also after some trial and error with the CoreBluetooth API it appeared that I could register both iBeacon and normal core bluetooth transfer services simultaneously but not both services would actually work.
To workaround this limitation I decided to poll these services – offer a few seconds of iBeacon paging, then tear that connection down and then transmit merchant information over CoreBluetooth services. If the apps are set up correctly to handle this type of polling elegantly then the user experience is seamless and this works pretty well.
While developing I was using iOS 7.0 and 7.1 – both known to have some iBeacon disconnection issues (as I was to find out later) and both seemed to need a hardware reset of the devices to get ranging working again. Despite this I was confident this issue would be eventually resolved by Apple and the recent 7.1.2 update is purported to have much better iBeacon stability.
For those looking to get into the nuts and bolts of iBeacon I can’t recommend highly enough the example projects out there on the internet to get started. Bear in mind that some versions of iOS prior to 7.1.2 will have problems disconnecting or not connecting with iBeacons – they will work and then stop working sporadically and only a hardware reset of the device will allow you to start ranging again (turning bluetooth on and off doesn’t work). However if you have two iOS devices and can easily debug them both you can get a great idea of how iBeacon ranging and range changes work. It’s simple, it’s intuitive and the possibilities are intriguing.