How long BLE app development takes, and why certification sets the date

ยท 9 min read

Every page that answers this question says four to twelve weeks. That range is roughly right for the app, and roughly irrelevant to your launch date. On a product with a radio in it, the app is usually not the long pole. Approval is, and it runs on its own calendar in each market you sell into.

There are two clocks, and only one is engineering

The engineering clock is the one everyone quotes: scan, connect, protocol layer, reconnection, backgrounding, then OTA if it is in scope. Six to ten weeks is a reasonable planning figure for a typical sensor or controller integration when hardware is on the desk and the protocol is written down.

The compliance clock starts when the hardware design freezes and has almost nothing to do with the app team. It runs in parallel if you start it on time, and in series if you forget, which is the usual way a launch slips by a quarter.

The Bluetooth SIG clock, which applies everywhere

Any product that uses Bluetooth technology has to be qualified with the Bluetooth SIG and carry a Declaration ID before it ships, in every market. This is not a regional requirement you can skip for a soft launch. It requires membership, and the fees and process differ depending on whether you are using a qualified module or a design of your own.

The good news is that this is largely paperwork if you built on a pre-qualified module and did not change its radio behaviour. The bad news is that teams routinely discover it exists about two weeks before they wanted to ship.

The radio clock, which is different in each market

United States. A device with an intentional radiator needs FCC equipment authorisation under Part 15, handled through an accredited test lab and certification body rather than by self-declaration.

United Kingdom. Post-Brexit the marking regime is UKCA, though the government has extended recognition of CE marking for many goods, so confirm the current position for radio equipment rather than assuming either answer. Radio equipment falls under the UK Radio Equipment Regulations, the domestic descendant of the EU Radio Equipment Directive.

Australia. Compliance is administered by the ACMA, and the device carries the RCM mark. The supplier has to be registered on the national database and hold the compliance records, which is a step teams miss because it is administrative rather than technical.

Each of these takes weeks rather than days once testing starts, and lab capacity is a real constraint you do not control. Book early.

One decision collapses most of this

Use a pre-certified radio module and most of the radio testing becomes an inheritance rather than a project. Module vendors carry approvals for the major markets, and a product that uses the module within its stated conditions, including the antenna it was approved with, can generally rely on them.

Design your own radio, change the antenna, or run the module outside its approved conditions, and you own the full test campaign in every market. That choice is made by the hardware team early, often without anyone connecting it to the launch date, and it is worth asking about explicitly.

The App Store clock

Small compared to the others, and still capable of costing you a week at the worst moment. A reviewer has to be able to evaluate an app that is useless without a device they do not have. Write the review notes early, explain what the hardware does, and give them a demo path that works without it. This is the same problem as testing without hardware, and the same answer: a mock peripheral or a recorded session.

A calendar that survives contact with reality

  • Hardware design freezes. This is the real start of the compliance clock, not the day the app work begins.
  • Book lab time immediately. Capacity, not paperwork, is usually what delays this.
  • App engineering runs in parallel, six to ten weeks for a typical integration.
  • Bluetooth SIG qualification and Declaration ID. Mostly paperwork on a qualified module, and a real project if not.
  • Radio approval per market, in parallel where the module allows it.
  • Field testing on real devices, in pockets and cars, with the screen off. Nothing on a desk predicts this.
  • App Store submission, with review notes written for someone who has no hardware.

What actually makes it slower

Not the app, usually. In order of how often they are the culprit: firmware that is still changing while the app is built, a protocol nobody wrote down, one prototype unit shared between everyone who needs one, and a decision to redesign the antenna after the module was chosen.

Three of those four are free to fix and none of them are the app developer's to fix. They are decisions, and they are cheapest in the week before anyone starts building.

The app is rarely the long pole. Lab capacity and a moving protocol usually are.

Rules and fees in all three markets change, so confirm the current position with a test lab before you plan around any of this. If you want a second opinion on whether your app timeline is realistic against the rest of the programme, send over the protocol document and the hardware spec and we can work through it.