Building Cross-Platform iBeacon Apps for iOS, Android and Windows with C# and Xamarin

This is a $5 Qualcomm Gimbal beacon in iBeacon mode, being detected on an Android phone and an iPhone, in an app built with C# and Xamarin:

Note that there is no Windows Phone in this picture. This is because the brand-new Bluetooth Low Energy (BLE) support in Windows Phone 8.1, which became publicly available last week as a developer preview, does not include BLE beacon support (and neither does Windows Store 8.1).

In this post I will show the why, with what and how of building iBeacon functionality in iOS and Android Apps, and what I have learned along the way – including how I verified the current limitations of the Bluetooth Low Energy support in Windows Phone & Store 8.1.

What iBeacons are (for)

iBeacons provide real-world context for your apps with micro-location information – outdoors and indoors.

Since the introduction of iBeacons by Apple in mid-2013, more and more companies see opportunities for using Bluetooth Low Energy (BLE) beacon technology in mobile apps. iBeacon is both a brand and a standard for BLE beacons by Apple; BLE beacons from most manufacturers are iBeacon compatible. BLE beacons allow apps on iPhones, Android phones and other mobile devices to respond automatically when a user gets close by – even when the app is not running in the foreground or when the phone is locked.

Most BLE beacons are small, cheap ($5 – $30), battery or USB powered devices. BLE beacons typically have a maximum range of 50-70 meter (in reality half that) and work well indoors as well as outdoors. This complements the capabilities of other proximity and location technologies: NFC has a range of only 4-20 cm (and is not supported on Apple devices), while GPS is less accurate and does not work well indoors.

BLE beacons provide two types of functionality: geofencing aka region monitoring to signal an app when someone enters or leaves a geographic area, and proximity aka ranging to determine how close someone is to a beacon. Ranging only works when an app is running in the foreground, while region monitoring also works when an app is not running (on iOS 7.1, the app does not even have to run in the background, which means that once the app has run once it will never stop responding until the user uninstalls it, revokes the Bluetooth permission for the app, or turns off Bluetooth altogether).

The combination of greater indoor range, accuracy, low energy usage in apps, mobile or stationary beacons and cheap hardware enables many new real-world scenarios. Common scenarios are for retail stores, restaurants, gyms, events and other situations where consumers visit (indoor) locations.

Typical applications are marketing (combining online behavior with detailed on premise behavior, sending special offers on entering a store), customer service (provide detailed information on-site; e.g. how do I work this machine in the gym?), waiting times (know how many people are in line before I go there?), social (automatic check-in), payment (with PayPal or mobile wallets)… and then there are the scenario’s where the beacons themselves are also mobile (on people, pets, key chains, cars…).

Mobile device support

Beacons that are compatible with Apple’s iBeacon standard will work with devices that have Bluetooth 4.0 and iOS 7.0+ (e.g. iPhone 4S+, iPad 3+), Android 4.3+ (e.g. Samsung Galaxy S3/S4/S4 Mini, Samsung Galaxy Note 2/3, HTC One, Google/LG Nexus 7 2013 version/Nexus 4/Nexus 5, HTC Butterfly), or OS X Mavericks 10.9+ (e.g. a MacBook Pro).

Which beacon is best?

There are many brands of beacons, differing widely in size, looks, features and price. However the actual hardware specs and cost is just part of the decision which beacon(s) to use.

Other important considerations are the backend services that serve as a beacon ‘content management system’, where you can manage beacons, define regions, analyze visitor behavior etc. The app is just part of the story – often you also need some sort of backend.

Then there is the client-side SDK, which determines what beacons feature are available on which platforms and platform versions.

And last but not least, there is the ability of the manufacturer to deliver reliably and in quantity, and the likelihood of the manufacturer surviving beyond the short term.

Here is an overview of some well-known beacons; below you can find which manufacturers I think are the strongest contenders.

Battery powered: Qualcomm Gimbal beacons

For battery powered beacons, Qualcomm is a relatively new player on the beacon field with its Gimbal beacons, but a very strong contender. Qualcomm is a major player on the wireless semiconductor market ($24.9 billion revenue in 2013); its offering has raised the bar for the entire beacon industry.

Gimbal has several beacon types, with the smallest ones very cheap: $5 (most beacons are $30 or more). Gimbal beacons can be configured in a standard iBeacon mode (iOS 7+, Android 4.3+), but also in a custom mode for which the Gimbal SDK supports iOS 7+ (87% runs on iOS 7+) and Android 2.2+. Given the amount of older (pre 4.3) Android devices out there, that is something to consider: (14% runs on 4.3+, while 2.2+ means 100% coverage).

The Gimbal backend services offer proximity, geofencing and interest sensing (an e-commerce analytics service for brick and mortar locations). And they are accessible through a REST API. If you use the Gimbal backend services, tracking up to 10000 users per month is free; after that it costs $0.06 down to $0.04 per user per month. You can also roll your own services, or use the beacons in iBeacon mode with other existing services.

USB powered: Radius Networks RadBeacon USB, PassKit GemTot USB iBeacon

If you need stationary beacons indoors, you can get better results with an USB-powered beacon such as the RadBeacon USB from Radius Networks or the GemTot USB iBeacon from PassKit.

Battery-powered beacons have to strike a careful balance between signal strength, advertising interval and battery life. USB-powered beacons do not have these limitations; they can transmit at full power and with a low advertising interval all the time, resulting in better range, faster response times and better accuracy. Plus you do not have to perform ongoing battery level monitoring and battery replacement every few months or years.

On a side note, there are currently some concerns about battery-powered beacons and how Apple is going to handle their iBeacon brand compatibility requirements: Apple reportedly requires a fixed 100 ms interval, which would severely limit the battery life of most battery-powered beacons. For details, see Apple iBeacon Specification: Why Power Matters.

The RadBeacon USB is a tiny $29 – $21 iBeacon compatible USB-powered beacon. It uses USB for power only; you do not need a computer (except when you want to reconfigure the beacon). You can stick the beacon in a cash register or in any cheap USB outlet adapter, plug it in an outlet (e.g. above your store ceiling tiles), and just skip battery maintenance and tweaking of send power level/rate settings.

Radius Networks offers backend services for configuring geofences and iBeacons, and an SDK to access the services from Android and iOS. Radius Networks also maintains an open source version of their Android Beacon Service Library, as well as several handy tools and apps for beacon app development on iOS and Android.

The GemTot USB iBeacon is a similar $25 – $17.50 USB powered beacon. In contrast to other parties, the backend services and API offered by PassKit are focused on integrating mobile wallets; they support Passbook, Samsung Wallet and Google Wallet.

Development beacons

Any iOS 7+ device with Bluetooth 4.0 can also be configured to act as an iBeacon, e.g. with the MacBeacon for OSX or the Locate for iBeacon iOS apps, which comes in handy for testing and development purposes. If you have no suitable iOS device handy, you can also use Radius’ Networks free Linux virtual machine to turn a cheap BLE USB dongle into a beacon (if for some reason you can’t get your hands on a real USB iBeacon quickly enough).

How to put a Gimbal beacon in iBeacon mode

The first thing to do is to put the Gimbal beacons in iBeacon mode (this is not the default). To do this, you need to install the Gimbal Beacon Manager app on an iPhone (note: the app is in the USA store so you may need to switch to a USA account on your iPhone) and follow these steps (source):

1. Login to the Gimbal developer portal at https://manager.gimbal.com/
2. Open the Proximity tab. Select the Actions button at the top right and then Manage Configurations.
3. Create a new configuration, select iBeacon as the beacon type, assign UUID, major and minor. You can choose any UUID you’d like; e.g. use http://www.uuidgenerator.net/.
4. Now register your Gimbal beacon, and select your new configuration for the beacon. You must open the beacon to get to the Factory ID that is required to register.
   
   
5. Open the Gimbal manager app on your iPhone, and select the Configure option.
6. Open the Gimbal beacon, remove the battery, put the battery back in. Now you should see your beacon in the Gimbal Beacon Manager app.
7. Click the Update button. Now your beacon will get a firmware update if needed, as well as the settings from your new configuration.
   

Note that even if you only target Android for your app, you still need an iPhone to configure Gimbal beacons.

Developing an iOS iBeacon App with Xamarin

Here is what you need to develop an iBeacon app for iOS with Xamarin:

• Optionally, a PC with Windows, Visual Studio 2013 and the Xamarin extensions for Visual Studio. Alternatively, you can build your app entirely in Xamarin Studio on a Mac.
• A Mac, to build and package your app with Xamarin and to create a UI with Xamarin + XCode. Preferably a Mac with OS X 10.9 and Bluetooth 4.0 support so you can also detect and simulate iBeacons. Note that even if you develop in Xamarin iOS on a Windows machine with Visual Studio, you still need a Mac to build and package your app and to create a UI in XCode.
• An iPhone 4S+ or iPad 3+ with iOS 7+ (BLE does not work in emulators, you need a real device).
  Preferably iOS 7.1 since that brings a major iBeacon improvement.
• I used the ScanBeacon for OSX app on the Mac and the Locate for iBeacon iOS app on the iPhone to detect and simulate iBeacons.
• Preferably, some real iBeacons. I used Gimbal.

Here are the steps to get the example Xamarin iOS iBeacon app Find the monkey working with an iBeacon-mode Gimbal:

1. Download the source from GitHub: https://github.com/mikebluestein/FindTheMonkey
2. Change the hardcoded beacon UUID to the UUID set in the Gimbal iBeacon profile:
   
   https://github.com/mikebluestein/FindTheMonkey/blob/master/FindTheMonkey/FindTheMonkeyViewController.cs#L15
3. Build and deploy to iPhone with Xamarin. Run and presto!
   
   

So there you have it, a Gimbal beacon working in C# in an iOS iBeacon app. A good starting point to experiment!

In a next post, I’ll describe the possibilities, strengths and limitations of the iOS iBeacon API’s.

Developing an Android iBeacon App with Xamarin

Here is what you need to develop an iBeacon app for Android with Xamarin:

• A PC with Windows, Visual Studio 2013 and the Xamarin extensions for Visual Studio. Alternatively, you can build your app entirely in Xamarin Studio on a Mac or PC.
• An Android 4.3+ phone with Bluetooth 4.0 (BLE does not work in emulators, you need a real device).
  I used an LG Nexus 5 with Android 4.4.2.
• Highly recommended: the Xamarin.Android binding of the open-source version of Radius Networks’ Android iBeacon Service.
  This library builds on top of the lower-level Android BLE API, to provide an API similar to the iBeacon parts of the iOS Location SDK. This adds functionality and makes sharing iBeacon code across platforms simpler. The library also includes a BluetoothCrashResolver module, which recovers from and prevents BluetoothService crashes due to Android Bug 67272. This bug makes an Android device unusable for BLE scanning after some time, especially with Gimbal beacons.
  Note that you need at least version 0.7.6 of the library, for which I submitted the Xamarin bindings in this pull request (expected to be merged soon).
  Also note that features such as background functionality are in the pro version of the library, which is not open source, and although it is free for development, it is not free for production ($9 – $3900 / month).
• I used the Locate for iBeacon Android app on the iPhone to detect and simulate iBeacons.
  
• Preferably, some real iBeacons. I used Gimbal.

Here are the steps to get the Android version of the example Xamarin iBeacon app Find the monkey working with an iBeacon-mode Gimbal:

1. Download the app source, which includes the binary of the 0.7.6 library, from GitHub: https://github.com/MacawNL/FindTheMonkey-Android

   Note that once my pull request has been merged, you can download this from the original https://github.com/mikebluestein/FindTheMonkey

2. Change the hardcoded beacon UUID to the UUID set in the Gimbal iBeacon profile:
   
   https://github.com/MacawNL/FindTheMonkey-Android/blob/master/FindTheMonkey.Droid/MainActivity.cs#L18
3. Build and deploy to Android phone with Xamarin. Run and presto!
   
   

Beacon ranging accuracy compared on Android and iOS

After playing around with both platforms, it became clear that even when using the same beacon, Android can give very different results from iOS. Apart from hardware differences in phones, the Android BLE API currently has some limitations which result in lower beacon accuracy.

As described here, the algorithm in the Radius Networks Android iBeacon Library is not the same as in iOS CoreLocation, because the iOS CoreLocation implementation is closed source. The intention is that they behave in a similar way. However, currently some Android limitations exist that cannot be overcome by a library:

“On Android, the Bluetooth LE Scan API only allows a single signal strength measurement per scan. On iOS, it is possible to get a different measurement for each advertisement broadcasted. By default, the Android iBeacon Library does one bluetooth scan every 1.1 seconds when it is in the foreground, therefore allowing one measurement every 1.1 seconds. So if you have an iBeacon that is transmitting 30 times per second (as iOS devices acting as iBeacons do), iOS will be able to get 300 samples in a 10 second period, and Android only 9. This explains why the estimate has higher noise on Android.”

Combined with the known Android bug, this confirms that even though iBeacons do work and are usable with some workarounds on Android 4.3+, the OS support is less mature than on iOS. Currently both Android and iOS are moving targets, although iOS still seems to be improving faster.

Windows Phone/Store 8.1 BLE beacon support

Which brings us to the current state of BLE beacon support in the ‘third’ mobile OS: Windows Phone 8.1 and Windows Store 8.1.

When BLE support was announced for Windows Phone 8.1 at the Microsoft Build 2014 conference, I assumed that BLE beacon support would be included. However, in the session Building Great Bluetooth Apps for Windows Phone two limitations were mentioned:

1. In the developer preview of Windows Phone 8.1, BLE is disabled for Nokia phones. This will be enabled on the final release of Windows Phone 8.1.
   (video at 6:50, PowerPoint slide 6)
2. BLE beacon support is something that Microsoft might add after Windows Phone 8.1 (video at 7:20, PowerPoint slide 7).
   Since two more updates to Windows Phone 8.1 are planned this year, the best case scenario would be June/July or November/December.

The last point obviously is a real disappointment. Since there is a lot of interest in beacon apps right now, I set out to verify both points and to see if I could find a way to get beacons working on Windows Phone 8.1 though a lower-level BLE API.

BLE disabled on Nokia Lumia’s with Windows Phone 8.1 Developer Preview

A fundamental difference between BLE beacons and other types of BLE devices is pairing. Pairing establishes a one on one relation between the BLE device and your phone, so that only your phone will be able to read e.g. your BLE heart rate sensor. BLE beacons by definition establish no relation to a device, except for encrypted functions. Since the Gimbal beacons used in this test can receive firmware and settings updates from the Gimbal Beacon Manager iPhone app, I expected that the procedure used to pair beacons to the Gimbal app would just be regular BLE pairing.

So I took a Microsoft Surface Pro tablet with Windows 8.1, which has BLE enabled, selected Add a Device and then rebooted the beacon by removing and inserting the battery. Sure enough, the Gimbal beacon was detected for a few seconds (after which it goes into regular beacon mode):

I took out my trusted Nokia Lumia 920 running on the Lumia Black update (which adds BLE support) and Windows Phone 8.1 Developer Preview, and repeated the procedure. The Gimbal was not detected. Ergo, BLE disabled is confirmed.

BLE Beacon support in Windows Phone 8.1 and Windows Store 8.1

This is the big one. Is there a way to use beacons with the BLE support in Windows Phone 8.1?

The MSDN documentation on the BLE support added in Windows Store 8.1 states:

“Bluetooth Classic and Bluetooth Smart devices must be first discovered and paired via the Windows 8.1 PC settings UI (PC & devices>Bluetooth) before being accessible via the Windows Runtime APIs for Bluetooth”

Here Bluetooth Smart is another term used for BLE devices. Determined to get to the bottom of this, I set out to verify this limitation and to see if a lower-level API might offer a workaround.

Starting at the bottom, the raw Bluetooth packets for iBeacons are described here (again, thanks to research by Radius Networks). This told me that I was looking for a Bluetooth Generic Attribute Profile (GATT) API to get access to the beacon advertisement packets. Keeping that in mind, I started out with the code used in the Building Great Bluetooth Apps for Windows Phone Build session to find a BLE device:

As it turns out, the BluetoothLEDevice class is only supported on Windows Phone 8.1, not on Windows Store 8.1. However, BluetoothLEDevice.GetDeviceSelector() is only used here to obtain a limiting filter on which devices we want. Since the DeviceInformation class is supported on both Windows Store 8.1 and Windows Phone 8.1, I could simply omit the filter and call DeviceInformation.FindAllAsync() in a Windows Store 8.1 App on my Surface Pro, which I verified has working BLE:

This returned over 300 entries – but none of them the Gimbal beacon that was detected on the same device earlier (I never paired it though – pairing the Gimbal beacon fails). Just to be sure, I tried the GattDeviceService Bluetooth Generic Attribute Profile (GATT) API that is supported on Windows Phone 8.1 and Windows Store 8.1:

Same result. Upon inspecting the GATT API in the Windows.Devices.Bluetooth.GenericAttributeProfile namespace, it quickly became clear that the only way to discover devices is through the DeviceInformation class, which currently only returns paired devices.

So again, no BLE beacons in Windows Phone 8.1 and Windows Store 8.1 is confirmed. We will just have to wait until Microsoft provides BLE beacon functionality in a post-Windows Phone 8.1 update (hopefully before Windows Phone 9).

Conclusions

BLE beacons enable many interesting real-world scenario’s, based on indoors as well as outdoors micro-location information, with cheap stationary or mobile beacons, where apps can react to proximity without running in the foreground or requiring action from the user.

BLE Beacon hardware and backend service offerings are maturing rapidly, as is support for the iBeacon standard in iOS devices (87% runs on iOS 7+). Support for iBeacons in Android devices is also there but still has limitations on accuracy, on the percentage of devices in use that support it (14% runs on 4.3 or later), although beacons that are not iBeacon compatible allow full Android device coverage. Android also has a stability issue that needs a workaround. Windows Phone 8.1 cannot support BLE beacons yet; beacon support is expected in an update within 3 to 12 months.

Last but not least, Xamarin once again proves to enable quick and full access to new native capabilities such as Bluetooth Low Energy beacons on iOS and Android, while also enabling code sharing across both platforms.