Which might come as a surprise to manufacturers of iBeacon devices, who have so far been required only to self-certify their compliance with the Apple iBeacon specification.
But device makers who rely on batteries instead of a plugged in power source are making trade-offs that may put them in conflict with the iBeacon specification.
This conflict, between how battery-powered beacons are developed and deployed and Apple’s requirements for power and advertising intervals, may lead to future problems if Cupertino decides to turn it’s eye to enforcing the use of the iBeacon trademark and ‘certification process’ for beacons.
What is an iBeacon?
By way of background, Apple only recently allowed manufacturers to apply to use the iBeacon name on their devices.
A beacon is any device which broadcasts a signal that can be used by a phone, tablet or other device to detect proximity. Most beacons on the market today are using the Bluetooth Smart proximity profile as the signal of choice. Audio signals and signals embedded in lighting are alternative types of signals.
A Bluetooth Smart (or Bluetooth low energy) beacon works with Apple, Android and other devices.
Apple, however, has gone a step further by granting beacon manufacturers the right to use its trademark name, iBeacon, on their devices. They have published a specification not dissimilar to the MiFi program.
The Apple web site states that beacons are not part of the MiFi program:
I want to develop an accessory that communicates with an Apple device using only Bluetooth Low Energy. Do I need to join the MFi Program?
No. Accessories which connect to an Apple device using only Bluetooth Low Energy/BTLE/Bluetooth 4.0 or standard Bluetooth profiles supported by iOS are not part of the MFi Program.
Thus, iBeacon seems to stand alone. It has certification guidelines that manufacturers need to review after they sign an NDA and specifications for the use of the iBeacon trademark.
According to insiders with knowledge of the specifications, manufacturers are required to adhere to a list of very specific technical criteria. The purpose is to ensure that the quality of the beacon and, thus, the satisfaction of both the company purchasing the beacon and the end consumer who interacts with it meet Apple standards.
It’s these specifications which are the source of a future potential conflict between Apple and those using the iBeacon trademark.
Tradeoffs: Beacon vs User Experience
It would be great if buying and deploying beacons was dead easy. But it isn’t. Both the manufacturer and the company buying beacons plays a role in deciding how it’s deployed.
On the manufacturer’s side, beacons have firmware that can be radically different from one product to another. Some use advanced algorithms to monitor and manage beacon power states – turning off at night in a store, for example, in order to conserve battery life when beacons aren’t used as often.
Developers, meanwhile, (or retailers or museums) can also make decisions when they put a beacon on the wall. Most beacons now come with configuration options allowing you to set the beacon up based on its use. For example, a single type of beacon can be configured for:
- The front door of a store. It doesn’t need to broadcast FAR but you want the reaction of your customer’s app to be nearly immediate.
- The parking lot – where the beacon needs to broadcast a larger distance but you don’t mind if it takes some time for the push message to reach your customer.
Between the manufacturer’s settings and how you deploy it in ‘the wild’, you’ll be changing the Tx Power, advertising interval, ID numbers and other factors.
The main tradeoff you’ll be making is battery life versus user experience. The “tighter” your user experience, the more battery you’ll be using because you’ll be broadcasting your signal at a higher rate.
Power Up Your iBeacon
But here’s the challenge: the Apple specification requires a high advertising rate. Insiders with knowledge of the specification tell us that it’s a fixed 100 ms interval.
The problem? Many battery powered beacons on the market today, if configured to broadcast at that interval, would have a dramatically reduced battery life. Beacons which might last a year at, say, a 1000ms advertising rate would last less than a few months in order to meet the Apple specification.
In other words, in a world populated with battery-powered beacons, the Apple specification is not your friend.
But why has Apple done this, and why should they care? In part, their focus is on the end user – the consumer. Because the second side of the tradeoff is the user’s phone, the power used to scan for beacons, the power saved if you can detect beacons faster, and the general responsiveness of a beacon-powered app and the ‘feeling’ of the user’s experience.
With all these things taken together, the only real solution is to avoid batteries altogether if you still want to adhere to the Apple iBeacon specification – or be prepared to change batteries every 30-60 days.
For example, the Radius RadBeacon or the newly launched GemTot are two USB powered beacons that you can plug into a wall or computer USB port. Because you don’t need to worry about battery life, youcan broadcast to your heart’s content. You’ll be meeting both the Apple specification and creating a highly responsive user experience.
Will Apple Crack Down on iBeacon?
But does Apple care? I guess it depends on whether you believe Apple will want more, well, power.
Insiders tell us that Apple has reserved the right to retroactively audit devices carrying the iBeacon trademark.
Whether the current specifications give manufacturers enough wiggle room is unknown. Adherence to the iBeacon specification is entirely self-reported by device makers. Perhaps in signing off on being an iBeacon device they’re simply saying that their device could advertise at the required frequency.
But without Apple making its specifications public, that would mean that many retailers or developers are using beacons that carry the iBeacon name but deploying them in ways that don’t adhere to the iBeacon specification.
A retailer might like to know, for example, that “if you broadcast at a lower signal that 100 ms, you are no longer iBeacon compatible”….but there’s no easy way to clarify this because the spec itself and the standards that manufacturers need to adhere to aren’t public.
Whether Apple takes a step in the future to police the specification might only be known by Apple itself – or, perhaps, Apple hasn’t even decided as they sit back and watch a ‘becosystem’ that grows larger (and slightly more confusing) by the day.
Share Your Thoughts
We’d love to hear your input – anonymous or otherwise! In the comments or by e-mail. Because the iBeacon trademark leaves us, well, confused. So what does it mean to you?