Bluetooth app development cost: how to estimate yours

Agency pricing pages put a Bluetooth app somewhere between about $10,000 for something basic and $150,000 for a full IoT integration, with wearable projects quoted at two to ten months. Those are marketing ranges rather than research, and they are wide enough to be useless for planning. If you are pricing a companion app for hardware you are building, you need to know which end you are at and why.

The reason the generic calculators mislead you is that they estimate from screen count and feature list. That is the right model for software that talks to a server and the wrong model for software that talks to a radio.

Three assumptions that break

A standard mobile estimate quietly assumes three things, and all three are false for Bluetooth work.

The first is that you can test in the simulator. CoreBluetooth does not exist in the iOS Simulator. There is no radio to emulate and Apple has never shipped one. Every change to connection logic needs a physical phone, a physical peripheral and a person watching both. The edit-and-check loop that takes eight seconds on a normal app takes a minute or more here, and it cannot run on CI. Multiply that across a few thousand iterations and you have found a large part of the difference in cost.

The second is that the backend holds still while the app gets built. On a hardware project the backend is firmware, it is being written at the same time by a different team, and the characteristic layout agreed in week one is rarely the one that ships. Every change invalidates app code that was already tested.

The third is that one phone is representative. For a server-backed app, if it works on one iPhone it works on all of them. Bluetooth does not behave that way. Every manufacturer modifies the Android Bluetooth layer, so the same call behaves differently on a Samsung, a Pixel and a budget handset with different silicon. Some Samsung devices silently fail an MTU request issued immediately after connecting and need a short delay first. That is in no documentation anywhere. Somebody finds it by losing two days.

Estimate from the GATT table, not the screens

So price it from the thing that actually generates the work. Count four things, all of which come from the firmware spec rather than the designs.

• •Characteristics. Every one you read, write or subscribe to is encode, decode, error-handle and test. Budget around 8 to 10 hours each.
• •Connection states. Disconnected, scanning, connecting, connected, bonded, updating, low battery, out of range. Around 10 to 14 hours each to handle properly.
• •Background requirement. Nothing if the app only talks to the device while open. Around 200 hours if it has to sync in a pocket.
• •Phone models beyond the first. Twenty to forty hours each for test cycles and manufacturer-specific fixes.

Add a baseline app shell at 120 to 200 hours for navigation, onboarding, settings and store submission, and the same again for over-the-air firmware updates if you need them. A worked example, for a wearable sensor with eight characteristics, six connection states, background sync, one hardware version and four phone models:

At $85 an hour that is around $64,000. At $145, a common senior contract rate in the US although published medians run higher, it is around $109,000. For how those rates differ by market, see what a CoreBluetooth developer costs in the US, UK and Australia. Both figures sit inside the agency ranges, but now the number has reasons attached to it, and every line is one you can challenge.

Then add fifteen to twenty percent for firmware churn. That is not padding. The firmware will change, and this is the honest way to price it.

Where that budget goes

That total has a shape, and the shape is what tells you where it can go wrong. The splits below come from Bluetooth projects I have delivered, not from published benchmarks. They move with the peripheral: a lock with four characteristics and a fitness band streaming at 50 Hz do not distribute the same way.

• •Connection lifecycle is scanning, connecting, reconnecting, bonding, permissions and state restoration.
• •UI and app scaffolding is the part that resembles normal app work.
• •Device test matrix is real hardware against real phones.
• •Protocol layer is encoding and decoding your characteristics, framing and chunking.
• •Background behaviour is staying alive when the app is closed.
• •Integration churn is firmware moving under you.

The three things that move the number most

Background operation is the largest single multiplier. An app that talks to the device only while open is a different product from one that syncs in a pocket, and the gap is roughly 200 hours. On iOS you are implementing state restoration, where the system can terminate your app and relaunch it into the background with the restoration callback firing before anything else is ready. See CoreBluetooth state restoration for what that costs to get right. On Android you need a foreground service, the OS silently stops any scan running longer than thirty seconds without a filter, and since Android 12 the scanning permission needs either location permission or a neverForLocation declaration that filters some beacons out of your results. Teams that skip this ship an app that works in the demo and fails in the customer's pocket. It is the most common reason a finished-looking Bluetooth app comes back for a rescue. If background sync can wait for version two, the first budget drops sharply.

Android breadth costs real money, because each manufacturer's stack genuinely differs. A defensible minimum for a consumer product is a current iPhone and the one before it, a Pixel as the reference Android, a Samsung Galaxy as the largest install base and the most divergent stack, and one budget Android with different Bluetooth silicon. That is four phones, and each needs a real unit of your hardware to talk to. Published estimates put physical device testing at five to fifteen thousand dollars on a typical project, which matches what I see. Android is not one target, and treating it as one is how a project runs over in its last month.

Firmware updates over the air are the feature most often discovered late. If your device ships to customers and firmware bugs are possible, and both are always true, it belongs in version one. Adding it afterwards means there are units in the field you can never fix.

Underneath all three sits a variable that is not technical at all. The cheapest projects are the ones where the characteristic layout is frozen before app work starts. The most expensive are the ones where firmware and app are designed at the same time by teams that do not talk to each other. That is a management decision, and it is worth more than any framework choice.

On frameworks: cross-platform often costs more here rather than less. You inherit a wrapper library's bugs on top of the platform's own, and when something breaks at the radio layer you are debugging through an extra abstraction. The usual advice from people who do this daily is to write the Bluetooth layer natively even when the interface is Flutter or React Native.

Costs that arrive after launch

• •Bluetooth SIG qualification. Shipping a product that uses Bluetooth means listing it with the SIG, and the fee depends on membership tier and whether you are reusing a qualified design.
• •Operating system maintenance. Every September iOS ships and something in CoreBluetooth behaves differently. Budget for a yearly pass.
• •Store review for background modes. Declaring Bluetooth background capability invites reviewer questions, and a rejection costs a release cycle.

Four questions for anyone quoting you

These separate people who have shipped Bluetooth products from people who have read about them.

• •How do you test before the hardware is ready? A good answer describes a mock peripheral layer or a simulator they have built. A bad one is that they wait for hardware.
• •What is your reconnection strategy after the phone's Bluetooth is switched off and on again? This should produce a specific answer about state restoration and backoff, not a general one about error handling.
• •Which Android manufacturers have you shipped against? Anyone who has done this has Samsung opinions and will share them unprompted.
• •What happens to the estimate if the characteristic layout changes? A firm that has not thought about this has not worked alongside a firmware team.

A quote that arrives without anyone asking to see your GATT table was not estimated. It was guessed.

If you have a quote in hand and want a second read on it, or an estimate built from your actual firmware spec rather than a feature list, that is a short conversation and usually a useful one.