Human Experiences, Proximity, Augmented Reality and the Internet of Things

iBeacon and WWDC: The Secret Star and 3 Things to Watch

Bluetooth LE and iBeacon may be the secret star of the annual World Wide Developers Conference (WWDC), with BLE powering features that include a new Healthbook suite of applications and software development tools and protocols for a connected home.

The headlines are promising: your iPhone and iPad are about to get a lot more connected.

They’ll be both the remote control for the world around you (allowing you to, say, easily change the temperature in your home) and the dashboard on which everything from your heart rate to the number of miles you’ve run are displayed through Apple-quality interfaces.

Powering these abilities is a heavy reliance on Bluetooth LE (or Bluetooth Smart) – the protocols that allow devices to transmit small packets of data which nearby mobile devices can ‘hear’ and thus react to.

Coupled with this shift to a ‘smarter, more connected world’, Apple will make changes and updates to its iBeacon specification which may shake up the current landscape and power a richer, more robust future of proximity-based devices.

Bluetooth: The Unsung Hero

I sometimes think that Bluetooth LE is the unsung hero of the new Apple era.

When Apple launched the iBeacon brand name it did so with little explanation: did it refer to the beacons themselves? Or the software development kit? Was it a standard? Was it “Apple only”?

Regardless of their original intent, Apple managed to own most of the mindshare for Bluetooth LE proximity beacons under the name.

Even Gigaom was confused, calling the launch of Gimbal an iBeacon competitor, not realizing that at the time there was no particular difference between a beacon that called itself an iBeacon and, well, just being a beacon.

While the iBeacon trademark was inclusive of a wide range of meanings, Apple finally launched its manufacturer certification program and, whether by intent or accident,kept things obscure by not making the specification public.

Simply: a device that transmits a Bluetooth LE signal which conforms to Apple requirements for broadcasting interval (and a few other things) can apply to be called an iBeacon and to use the trademark.

The Underutilized Power of Bluetooth LE

The thing that makes BLE so powerful is how simple and ‘small’ it is. If you create a device that broadcasts a BLE signal, you’ve been given a lightweight protocol for sending a small packet of data that can hold a tremendous punch.

BLE provides a standard way to format and transmit this data. But its real power comes in the “profiles” you can build on top. There are 14 pre-defined GATT-based specification (see diagram).

The proximity profile is one such profile – think of it like a ‘variant’ on BLE which adjusts its advertising packet data to broadcast information specific to a proximity (or beacon) use case.

Other profiles include the Heart Rate Service and the Health Thermometer Profile.

Can you see where Apple might be finding (in part) the ability to launch a Healthbook?

But while BLE is powerful, Apple has abstracted the ability to dive deep. There are two things that Apple makes difficult to do:

Their SDKs are designed for ‘public’ connection to beacons. Meaning that while the beacon UUID number can be randomized or otherwise “secured”, Apple makes it difficult to use the BLE “private mode” where pairing is required before a device will ‘talk’ to your phone.

Their SDKs don’t allow you to make use of a BLE beacon “sub packet”. This is a small stream of data that can be tailored by the device maker – sending, for example, extra profile information or unique identifiers that go beyond Tx Power, RSSI, UUID and Major/Minor. In other words, there’s a beacon customization level that your iDevice can’t “see” and so beacon manufacturers can’t take advantage of the ability to highly customize the signal that a beacon sends.

Open Vs. Closed UUIDs

Apple has recently started rejecting apps that allow you to manually input UUID numbers. While Apple has always ‘locked down’ the ability for apps to scan for beacons that aren’t your own, there was always a back-door: give the user a way to manually input a device number, and let the scanning begin. (Android has no such qualms, allowing you to scan for beacons that aren’t your own).

There are ways around this, of course. If your beacon ID numbers are maintained in the ‘cloud’ you can always bypass the app itself and give users a tool to post new UUIDs to a ‘back-end’. Awwapps created a system for ‘open beacon credentials‘, for example, and posted the supporting code on Github:

Open iBeacon Credentials are meant to be used in isolated home environments and personal contexts. They are especially useful for apps that allow users to link their own iBeacons. Open Beacon Credentials provide a clear guidance on how to configure your iBeacon to make this connection work well.

In the context of the connected home, Apple is likely to launch a new certification program for devices that power your home: for thermostats and music players, your television (or Apple TV) and your baby monitor. This certification program is likely to open up new and expanded ways to connect to different BLE profiles with accompanying SDK and device-side interfaces (think Passbook for home management) to enable elegant user experiences.

But these too will rely on UUIDs so that your phone knows which device is which and doesn’t confuse the fridge for the toaster.

As your phone takes on the task of scanning for all kinds of signals and UUID numbers, the ability to manage limits (and not crash your phone, as has happened with Android).

With Apple ‘closing up’ the UUID loophole, they may simply be laying the groundwork for an era in which your phone needs to manage a lot more scanning and BLE detection.

Wild Guesses and Bold Predictions for WWDC

So what can we expect from WWDC? Well, let me take a few obvious guesses and maybe a few moon shot ones:

Bold Non-Prediction: Don’t Expect a Mobile Wallet or NFC

First, two things I DON’T expect to see: a mobile wallet or NFC.

While there have been rumors that Apple would suddenly switch course and embed NFC in its phones, I’d actually find it a surprise of monumental scope if they suddenly took that path.

I could, of course, be wrong. But rumors this week that Apple is in very early discussions with major retailers about mobile payments have me thinking that both NFC and an embedded mobile wallet still have a way to go.

Bold Prediction 1: Apple Will Fix Horrible Bugs with Beacons

Unfortunately, updates since then introduced a new and maddening bug where your phone would just randomly stop scanning for beacons, requiring a full phone restart in order to work again. It’s not much of a prediction to say that this bug will be fixed – although don’t expect mention of it in the Tim Cook keynote presentation (and don’t think you’ll have to wait for iOS 8 either).

Bold Prediction 2: Apple Will Offer iCloud Device Services

Perhaps a bolder prediction, and one that might be an optional service rather than a requirement, comes from thinking about the Awwapps open beacon credential system mentioned above.

Namely – it would make a lot of sense for Apple to offer an iCloud-based service for registering devices and their UUID numbers, offering a ‘single service’ that iDevices can access to discover which UUID numbers to scan for.

The move would make a lot of sense – perhaps less so for iBeacon devices in retail or museums, and moreso under the banner of connected health devices and the connected home.

Health devices, in particular, would point to such a move: if it’s true that Apple has been in discussions with the FDA and major healthcare organizations, the security and confidentiality of health information is likely a top priority.

Shifting UUID and device management to the Apple iCloud ecosystem would be done in the interests of consumer privacy and to give the ‘Apple stamp of approval’ on how devices are locked down. iBeacon proximity beacons might get caught up in a move to centralize the registration of devices (whether optionally or required).

Bold Prediction 3: With More Robust Tools, More Robust Beacons

If Apple, as predicted, announces a connected home initiative (iHome? iIsHome?) then they’re opening the door to devices that can do more things and can interact more seamlessly with Apple devices. Couple that with improvements to Apple Maps and we’ll see more precise and richer proximity-based experiences targeted to where you live, work and play.

The move to a connected home would have spillover effects in retail, in museums, in Tulip theme parks, or in the enterprise. Just when you thought you’d cracked the challenge of beacons and proximity, you’ll have a new set of tools for – well, for turning the lights on for one thing.

Will this lead, for example, to digital signage that’s responsive to customers in a store? If Apple were to create tighter integration between Apple TV and a ‘connected home’, it’s not a stretch to think that those same tools could drive displays in the cookie aisle or in a display at a museum.

Beacons, in other words, may be given more powerful collateral technologies that they can play with out of WWDC.

We’ll see. One thing for sure? Not a lot of BLE beacon companies or developers will be doing a lot of productive work on Monday. Instead, they’ll be tuned in for WWDC, looking for those hints tucked in the corner of the keynote slides of what the year ahead will hold.

5 thoughts on “iBeacon and WWDC: The Secret Star and 3 Things to Watch”

Hi Doug,
as always I love your thoughts at beekn.net and your bold WWDC 2014 predictions.
My bold prediction is an enhancement of Apple Maps for Indoor Navigation and to display Indoor Maps together with iBeacon technology and a public MapKit API upgrade for developers.
This will enable better user experiences for indoor use cases e.g. Shopping Malls, Retail Stores, Exhibitions, Museums…

It is good to remember also that Apple does not own Bluetooth 4.0
It is still possible to develop beacon-like products that implement whatever rich instruction repertoire way out of the context of an iBeacon. And use Core Bluetooth i iOS to talk to a device that speak this repertoire. Or the Android SDK. But that Bluetooth product might not be branded with an Apple owned trademark. This Apple certification thing in the Bluetooth arena is for products that claim compatibility with Apple trademarked features based on Bluetooth 4.0