BLE app development: the market behind the hardware

There is a forecast on the Bluetooth SIG’s market dashboard that reframes what a mobile app is for. By 2030, 99% of all Bluetooth devices shipped will include Bluetooth LE — and over the same period, the number of smartphones shipped each year goes slightly down.

The growth is not in the phone. It is in the things the phone talks to. If you make one of those things, the app is not an accessory to your product. For most of your customers it is your product, because it is the only part with a screen.

This post is about that market and what building for it involves. The engineering side is a separate piece.

Bluetooth is becoming Bluetooth LE

Three radios ship under the Bluetooth name, and they are going in three different directions.

Single-mode Bluetooth Classic is being designed out — it is the radio in a decade of audio accessories, and it is shrinking fast. Dual-mode radios, the kind in a phone or a laptop, grow about as fast as the phone and laptop market does, which is to say barely. Bluetooth LE grows at 19.6% a year.

That is the number worth sitting with. It is more than twice the growth rate of Bluetooth as a whole, and it is happening because LE is what you put in a device that has to run for a year on a coin cell.

The growth is not in phones

Here is the same forecast split by what the device actually is.

Smart labels grow at 86.5% a year. Electronic shelf labels, 40.1%. Commercial lighting, heating and security, 37.7%. Asset tracking tags, 29.2%. Continuous glucose monitors, 11.1% — from 70 million units a year to over 105 million.

Against that: smartphones at 2% down a year, tablets 3.2% down, laptops 3.4% down, and headphones falling 16.3% a year as the market moves to earbuds.

So the devices in the first list are multiplying, and the devices in the second list — the ones with screens — are not. Every product in the first list has to borrow a screen from the second.

Every one of those devices needs an app

A sensor with no display cannot tell you it has a problem. It cannot ask for your Wi-Fi password, show you last week’s readings, or let you know its firmware is out of date. All of that happens on a phone, or it does not happen.

The middle column is where products are won and lost, and it is routinely the last thing on a hardware roadmap. We see the result often enough to recognise the pattern: a competent device, shipped with an app written by the firmware team in the last six weeks before launch, which then accumulates support tickets that look like hardware faults and are not.

What BLE actually gives a user

Four things, concretely, rather than as adjectives:

• Setup without a password. The phone is already in the owner’s hand and already authenticated. A device can be commissioned by proximity and a tap, rather than by typing a key off a sticker.
• It works with no internet. A BLE product keeps working in a basement, on a farm, or during an outage. If your value proposition depends on your servers being up, you have built something more fragile than the hardware deserves.
• Battery measured in months. LE is designed for a radio that is asleep almost all the time. That is what lets a tag live in a shipping crate for a year.
• Distance that means something. This one is new, and it is the most interesting.

Where this is going

Core Specification 6.0 introduced Channel Sounding, a way for two devices to measure the real distance between them rather than guessing from signal strength. Signal strength has always been trivially spoofable, which is why a car that unlocks on proximity has been a security problem for years.

Channel Sounding measures distance two ways — phase differences across many frequencies, and the round-trip time of cryptographically scrambled packets. The Bluetooth SIG’s own figure for what is shipping today:

In early implementations of the Bluetooth® Channel Sounding feature, we are already seeing accuracy levels of +/- 20 cm.

Twenty centimetres is the difference between “someone is near the door” and “someone is at the door”. It makes digital keys, access control and genuine find-my-thing features possible on a radio that is already in everything.

The specification work has continued: Core 6.2 added protection against amplitude-based attacks on ranging, and cut the minimum connection interval from 7.5 ms to 375 µs for devices that need to feel instant. Core 6.3 is the current version, and Core 6.0 carries a deprecation date in 2035 — so a product designed against it today has a long runway.

What moves the cost of a build

An app that talks to hardware costs more than an app that talks to a server, and the reasons are specific rather than general. Our guide to what app builds actually cost covers the baseline; these are the things on top of it:

• Firmware you do not control. If the device team is a supplier, every protocol question becomes a scheduling question. The single best cost control on these projects is agreeing the data format early, in writing.
• The Android fleet. Bluetooth behaviour varies by manufacturer in ways that are not documented anywhere. You test on a matrix of real phones, and that matrix is a line in the budget.
• Field conditions. Range, interference, a phone in a pocket, a device at the end of its battery. These bugs cannot be found at a desk.
• Updates. Shipping firmware over BLE, to a device that might be switched off halfway through, with a way back if the new version is worse. This is a feature on its own and it is almost always scoped as a checkbox.
• The permission story. Android’s Bluetooth permissions interact with Play Store review. Get the strategy wrong and you are explaining yourself to a reviewer during launch week.

If your product is regulated

Continuous glucose monitors are forecast to pass 105 million units a year by 2030. That is one category, and it is a reminder that a lot of connected hardware is medical hardware.

If your device is a regulated product, the app is part of the regulated system — its data handling, its audit trail, and the claims its interface makes. The rules differ between Canada and the United States, and we have written a plain-language guide to which ones apply. Treat this as scope from the first week rather than a compliance pass at the end.

Where to start

If you have a device and no app, the first useful thing is not a design. It is a written protocol: what the device exposes, what the app may ask for, and what happens when each of those fails. Everything above it is cheaper to change than that is.

We do that work — BLE and connected hardware apps is what it looks like as an engagement. If you already have an app that works on the bench and not in the field, that is the more common version of this project, and it is usually a smaller fix than it feels like.