The watch app most teams should not build

Does smartwatch app development still make sense?

Smartwatch app development earns its budget in three situations: the user needs one number or one action in under five seconds, the phone is inconvenient or absent, or a body sensor is the data source. Outside those, the wrist adds cost without adding reach. Demand for the hardware is not the constraint. Wrist-worn device shipments, smartwatches and bands together, reached 150 million units in the first three quarters of 2025, up 10% against the same period a year earlier.²

What fails on the wrist is scope, not technology. Teams port a phone app to a 45mm screen, ship five tabs of navigation, then find that sessions last seconds. A single glanceable surface almost always beats the miniature app it was meant to launch, and it costs a fraction to build and to keep running.

So the useful question is not whether to be on the wrist. It is how little you can put there and still be worth the charge.

Do you need a watch app, or a tile?

Wearable app development has three delivery levels, and they differ by an order of magnitude in effort. A complication on Apple’s platforms and a tile on Wear OS are the same idea: a small element on the watch face or dashboard that shows live data without opening anything.

Most products should ship level two and stop. A delivery status, a glucose reading, a next appointment, a shift task count, a door lock button: these are complete products at tile scale. Build the full app when the user genuinely needs to act on the watch for longer than a few seconds, or when the watch itself is the sensor.

The test we use in scoping: write the one sentence the user would read on the wrist. If the whole value fits in that sentence, a tile is the product and the app is packaging.

Standalone or companion: the decision that sets everything else

A companion app depends on Bluetooth proximity to the paired phone and borrows the phone’s identity, network and processing. A standalone app runs and syncs over cellular or Wi-Fi with no phone present. Deciding this on day one avoids a rebuild, because standalone is not a switch you flip in release three.

Going standalone means the watch needs its own authentication and token refresh, its own offline queue with conflict resolution, its own network failure handling, and an API surface tolerant of tiny, intermittent, high-latency requests. It also means paying for that in battery and in the user’s cellular plan. Roughly, it is a second client, not a screen.

One question settles it. What must the user be able to do when the phone is in a locker, a car or another room? A warehouse picker, a runner, a swimmer, a nurse on a ward and a field technician all have real answers. Most consumer and productivity apps do not, and a companion architecture serves them better and cheaper.

watchOS or Wear OS: which platform first?

Start with the platform your existing users already carry, not with the global share table. watchOS development is only reachable by iPhone owners, because Apple’s watch pairs with iOS alone, so an Android-majority user base makes Wear OS apps the first build regardless of what worldwide vendor rankings say.

The vendor picture explains why the answer is rarely obvious. Apple led global smartwatch unit share in 2025 at 23%, ahead of Huawei at 17% and Xiaomi at 9%, with Samsung and the children’s watch brand Imoo each at 7%.³ That is a market with one leader and a long tail, not a duopoly.

Growth sits elsewhere. Wear OS is forecast to grow at 17.25% a year through 2031 in North America, the fastest of any watch platform there,⁴ and China shipped 58.43 million smartwatches in the first three quarters of 2025, up 27.6% year on year on the back of subsidy demand.⁵ A product with international ambitions should plan for both, in sequence.

On tooling, be realistic about cross-platform frameworks. They remain weaker than native for complications, tiles and deep health data access, and teams chasing a single codebase across watchOS and Wear OS often rebuild the sensor layer natively anyway. Share the business logic and the API contract, as you would in any well-structured mobile application build, and accept that the wrist layer is written twice.

What health sensor data can a third-party app actually read?

Fitness-grade metrics are broadly available to third-party apps through the platform health stores: steps, heart rate, workouts, sleep, energy. Clinical-grade signals are not. Raw electrocardiogram waveforms and irregular rhythm notifications are far more restricted on watchOS than ordinary fitness data, and access is gated by entitlement review rather than by an API key. Wear OS exposes live sensor streams through its on-device health services, but the regulatory logic on what you may claim is the same on both platforms.

The practical consequence is a scoping rule: check what your feature list actually requires against what you can realistically be approved to use, before anyone promises clinical function to a customer or an investor.

Three rules keep health features shippable.

1. Write the claim before the code. Displaying a number is a wellness feature. Interpreting it, flagging it or acting on it is a medical claim, with the approval and liability that follow.
2. Separate the sensor layer from the interpretation layer. Sensor access rules change per platform and per region. Interpretation logic should be portable and testable without a watch attached.
3. Budget entitlement review as schedule, not paperwork. Restricted health capabilities are approved by a person, on their timetable, and that sits on the critical path.

The category is large enough to justify the discipline. Wearable healthcare devices are projected to grow from $45.29 billion in 2025 to $75.98 billion by 2030, a compound annual rate of 10.9%,⁶ inside a wider wearable technology market estimated at $96.48 billion in 2025.⁷

What does smartwatch app development cost and how long does it take?

Adding a companion watch experience to an existing phone app typically runs $12,000 to $18,000.⁸ A new watch extension delivered alongside its own mobile app runs $22,000 to $30,000 and takes six to eight weeks, with published midpoints of roughly $15,000 and $26,000.⁸ Complex enterprise builds, with fleet management, regulated data and a wide device matrix, run past $500,000.⁸

Four things move a quote out of those bands: standalone connectivity, regulated health data, the number of watch models under test, and always-on display support. Each one adds a work stream rather than a task.

Six to eight weeks is a build window, not a product window. Discovery, entitlement review, device procurement and store submission sit outside it, which is why watch work should enter the plan at the same phase gates as everything else in a normal software development life cycle rather than as a bolt-on sprint at the end.

Why battery, not screen size, is the real constraint

Small screens are a solved design problem. Battery is not. Retention on the wrist is lost to charge anxiety long before it is lost to layout, and the decisions that drain a watch are made in the architecture, not the mockups: background sync frequency, always-on display rendering, continuous sensor sampling and GPS sessions.

A watch app that visibly shortens the day between charges gets uninstalled, however good it looks.

Four habits protect the charge. Budget wake-ups explicitly and treat every background refresh as a cost. Render a genuinely cheaper variant for the always-on state instead of dimming the active one. Batch and coalesce sync rather than reacting to every change. Then measure battery drain per session as a release metric with a threshold, the same way a team would treat crash rate or cold start time in any disciplined engineering practice.

A scoping sequence that avoids the rebuild

1. Write the one sentence the user reads on the wrist. If it is complete, scope a tile or complication and stop.
2. Decide standalone or companion, in writing, with the phone-in-a-locker test. Record it as an architecture decision, not a preference.
3. Pick the first platform from your own install base, then set the trigger that starts the second build.
4. List every sensor the features need, and mark which ones require restricted access and review time.
5. Set a battery budget per session before design starts, and make it a release gate.
6. Only then price the build, and price the second platform separately rather than assuming a shared codebase will cover it.

Teams that follow that order usually spend less than they planned and ship something people keep. Teams that start from the feature list build a small phone app on a small screen, and pay twice when standalone or a second platform arrives. If you are scoping wearable work and want the architecture decisions pressure-tested before the budget is fixed, talk to our team.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.