Beyond the hype: what to look for in iBeacon and BLE hardware

No quod sanctus instructior ius, et intellegam interesset duo. Vix cu nibh gubergren dissentias. His velit veniam habemus ne. No doctus neglegentur vituperatoribus est, qui ad ipsum oratio. Ei duo dicant facilisi, qui at harum democritum consetetur.

There's a lot of hype and excitement about iBeacons and BLE hardware and the kind of interactions and use-cases that are now possible. At Localz, we’ve been working with iBeacon related software services since August 2013 (iBeacon was announced by Apple in June 2013) and learned what to look for to support retail and shopping deployments.    We’ll assume you know what iBeacon is and how it can be used.


iBeacon background

iBeacon is built around the Bluetooth 4.0 - Low Energy (BLE4.0) standard.  Technically, it’s possible to send iBeacon broadcasts on any device which allows customisation of BLE4.0 broadcasts.  Whilst Apple has not publicly disclosed the iBeacon protocol, we and others have reverse engineered the standard.  With standard in hand, any of us can use and deploy iBeacon.

For the hacker, detailed iBeacon protocols are published at:


iBeacon compatibility

BLE4.0 capable hardware is included in most recent smartphones.  Unlike older Bluetooth technology, it uses little power which means it can be enabled at all times.  However, not all BLE4.0 devices work natively with Apple’s iBeacon protocol.

For Apple devices, iOS 7.0 or later is required.  iBeacon compatible devices include

  • iPhone: 4s, 5, 5c, 5s

  • iPad: 3, 4, mini

  • iPOD Touch: 5th gen

With a bit of code hacking (bravo Gennadi), it’s possible to use iBeacon on select Android devices.  BLE4.0 capable hardware and Android API version 18 (Android OS 4.3) or later is required.  Tested and working Android devices include:

  • Google: Nexus 7 tablet, Nexus 4 and Nexus 5

  • Samsung: Galaxy SIII, Galaxy S4

  • HTC: One, One Max, One Mini, One X+, Droid DNA (the later as per HTC rep)

With any of the above devices, it’s possible to broadcast iBeacon notifications...but that would be expensive.


Our base device criteria

When we evaluate BLE4.0 hardware, we’re looking at deployment in retail, hospitality, entertainment and destination marketing locations.  For us this means:


  • small form factor: make it easy to put them anywhere….no eyesores

  • battery powered preferred: power outlets are sparse or not located in ideal spots and electrician services are expensive

  • long battery life: we don’t want to service these too often

  • radio range: we need devices capable of broadcasting 50 meters or greater

  • weather resistant: they need to operate in the cold Tasmanian winters, hot Australian summers, humid tropical locations and they need to work outdoors but in protected enclosures

  • certified: in many countries, radio emitting devices need to conform to national standards and pass a technical certification such as FCC (USA), IC (Canada), CE (Europe) and in Australia AS/NZS 4268 and Class License 2000


  • reliable and stable firmware: the software stack needs to run without issue 24 x 365

  • updatable firmware: there are likely to be changes to protocols and we need the ability to securely update firmware

  • adjustable radio power: for indoor placements, we need adjustable radio power to prevent cross-talk, at a minimum we need to adjust the RSSI setting

  • zero end user configuration: we want to make installation a frictionless experience

  • secure administrator configuration: only authorised applications and users should be able to change the device configuration

  • reportable battery life: we need to remotely read battery life to know when to service

Other considerations:

  • Supported protocols: not all devices support or adhere to Apple’s iBeacon protocol.  Whilst they may work with iOS, devices that use other protocols are unable to take advantage of native OS features like: background beacon detection, proximity OS notification, and OS controlled proximity ranging.

  • Production availability: iBeacon is a new technology. A lot of hardware developers jumped into the game but when pressed for inventory, not all can deliver production ready units.

  • Support documentation: we need devices to work in a commercial setting.  That means having well documented technical and operational standards.


What to know more and which hardware we're currently using for different use cases?
Signup for our newsletter or contact us.