Start with the unprofitable advice, because it saves most readers a five-figure decision: most fitness and wellness brands do not need an Apple Watch app. They need reliable HealthKit sync and possibly a complication. A watch app that mirrors the phone app is a well-known way to acquire one-star reviews about battery drain from users who never asked for it.
There are three things a watchOS app can do that a phone app cannot, and if none of them is core to your product, you should ship the HealthKit integration at $3,500 and spend the rest of the budget somewhere users will notice.
This page covers what those three things are, what they actually require to build, and what goes wrong.
The three reasons a watch app exists
1. Live workout sessions
This is the real one. HKWorkoutSession with HKLiveWorkoutBuilder is the sanctioned mechanism for an app to keep running on the wrist during exercise. Starting a workout session does three things nothing else does:
- It keeps your app running in the background for the duration of the session, rather than being suspended within seconds like every other watchOS app.
- It elevates sensor sampling. Heart rate is sampled far more frequently during an active workout session than in ambient mode. If your product depends on heart rate during exercise, this is the only way to get it at useful resolution.
- It reserves the screen. Raising the wrist during a workout returns the user to your app rather than the watch face.
If your product is real-time — interval coaching, zone training, live HR-driven feedback, guided sessions with haptic cues — you need a watch app, and specifically you need a correct workout session. There is no phone-side substitute, and no cloud API gives you Apple Watch data live.
Two implementation notes that cost teams real time. First, HKWorkoutSession requires the workout processing background mode alongside the HealthKit entitlement, and the configuration is easy to get subtly wrong in a way that works in the simulator and fails on hardware. Second, you must end the session and finish the builder. A session left running is a battery drain that the user attributes to your app and reports as such. Handle every termination path: user ends it, app crashes, user force-quits, the watch reboots.
2. Complications on the watch face
A complication is the most valuable real estate in consumer software: a permanent placement on a surface the user looks at dozens of times a day, with a tap that opens your app. For a habit or streak product, it may be the whole retention strategy.
What you need to know:
- Complications are WidgetKit now. ClockKit is deprecated; modern complications are built with the same widget machinery as iOS, which is good news if your team already ships widgets.
- Refresh budget is limited and not guaranteed. You provide a timeline of future entries and the system decides when to reload. You cannot update on demand whenever your server has news.
- Therefore design for staleness. A complication showing a number that's a few hours old is fine. A complication that shows a wrong number confidently, or a stale one with no indication, is worse than none. Show the value and, where it matters, when it was from.
- Always-on display matters. The watch dims rather than sleeping. Your complication and your in-app UI both need a reduced-luminance variant that isn't a bright block on the user's wrist in a meeting.
3. Glanceable interaction and haptics
The watch is good at one interaction: a two-second look and maybe one tap, or a haptic the user feels without looking. Logging water, marking a set complete, confirming a check-in, feeling an interval change. That's a genuinely good product surface.
It is not good at browsing, reading, forms, or anything with more than a handful of screens. Every fitness watch app that fails does so by attempting the phone app on a smaller display.
Independent vs companion: pick deliberately
An independent watch app runs without the iPhone — its own networking, its own auth, its own local storage. It works when the user leaves the phone at home, which is exactly when runners and swimmers want it, and it's what LTE and GPS-only-with-wifi watches make possible.
A companion app depends on the paired phone for data and often for network access. Simpler to build, and it breaks in precisely the scenario your athletic users care most about.
The default recommendation for fitness products is independent, and it has consequences you should price in:
- Your API has to be callable from the watch, with its own auth token lifecycle. Sign-in on a watch is a poor experience, so most teams provision the watch from the phone once and then let it operate alone.
- You need local persistence and a sync-on-reconnect story, because a watch that's been off-network for an hour has data to reconcile.
- You need your own error states. "Can't reach the server" on a wrist is a design problem, not a toast.
WatchConnectivity links the two when both are present, and its three transfer modes have different guarantees worth learning before you pick one. sendMessage is immediate but requires the counterpart to be reachable — it fails when the phone is in a pocket in another room. transferUserInfo queues and delivers in order, eventually, which is what you want for events like "workout completed". updateApplicationContext overwrites — it delivers only the latest state, which is what you want for "here's the current user profile" and exactly wrong for a sequence of events. Choosing sendMessage for something that must not be lost is the most common WatchConnectivity bug we see.
Background heart rate outside a workout
Founders frequently ask for continuous heart rate without a workout session. You can't have it the way you're imagining. Outside an active workout session, the watch samples ambient heart rate on its own schedule, writes it to HealthKit, and your app can be woken about it through an observer query with background delivery — the same mechanism described in HealthKit vs Health Connect vs Terra.
That gives you periodic readings, not a stream, and the frequency is Apple's decision, not yours. Any product design that assumes second-by-second passive heart rate is designing for a device that doesn't exist.
Battery is a product requirement, not an engineering detail
Reviews of watch apps are dominated by battery complaints, and the causes are almost always the same short list:
- A workout session that was started and never properly ended.
- Location updates at full accuracy for the whole session when a lower accuracy would do.
- Chatty WatchConnectivity — many small messages instead of batched transfers.
- Animations running under always-on display.
- Polling anything on a timer.
Treat battery as an acceptance criterion with a number attached, measured on hardware across a realistic session length. This is one of the specific reasons watch work needs real-device QA rather than simulator testing — the simulator will not tell you that your app costs the user 22% of their battery on a long run.
What else the platform gives you
- Digital Crown for precise scrolling and value adjustment. Underused and much better than dragging on a small screen.
- Water Lock for swim workouts, which you should engage during aquatic workout types.
- Double Tap on supported hardware for one-handed confirmation — good for "next set" in a workout flow.
- The Action Button on Ultra models, which endurance users expect to be able to map.
- Workout activity types and location types. Setting
HKWorkoutConfigurationcorrectly — the right activity type, indoor versus outdoor — affects how the watch calibrates and how the workout appears in the user's Fitness app. Getting it wrong makes your app the one that "logs runs weird".
What it costs, and how to sequence it
A watch app is a build, not an integration. The $3,500 wearable integration price covers reading Apple Watch data through HealthKit on the phone; it does not cover a watchOS app with its own UI, workout sessions and complications. That work lives in the MVP band on our pricing page — from $12,000 for a bounded version one — because it's a second client application with its own screens, its own state, its own release process and its own QA matrix.
The sequence we recommend for a fitness brand:
- HealthKit sync first. $3,500. Read the data the user's watch already generates. This alone answers most "does the app support Apple Watch" questions in reviews.
- A complication, if you have a daily number worth a glance. Small, high-leverage, and it tests whether the wrist matters to your users before you commit to a full app.
- A full watch app only if live sessions are your product. Interval coaching, zone training, guided workouts with haptics. If you can't name the live moment, you don't need it yet.
That order lets you find out whether wrist engagement is real for your audience before you spend on the expensive version. It's the same sequencing logic we apply to fitness app development generally, and for coaching businesses specifically on for fitness coaches.
Submission notes
Watch apps ship inside your iOS app's release. Two things to have ready before you submit: your HealthKit usage descriptions must be specific about what you read and why (generic strings are a routine rejection), and reviewers need to be able to exercise the watch functionality, which for an app behind a login means a working demo account. The wider list of what trips health apps up in review is in why health apps get rejected.
Frequently asked questions
Do we need an Apple Watch app to support Apple Watch?
No, and this is the most useful thing on this page. A HealthKit integration in your iPhone app reads everything the watch records — workouts, heart rate, steps, sleep, energy — with no watchOS code at all. You need a watch app when you need something to happen on the wrist during an activity, not when you need the data afterward.
How much does an Apple Watch app cost to build?
More than an integration and less than a phone app, but not by as much as you'd hope, because it's a full second client with its own UI, state, sync and QA. Budget it in the MVP band rather than as a line item on your iOS build, and scope it to one or two flows rather than porting your feature list.
Can the watch app work without the iPhone nearby?
Yes, if you build it independent: its own networking, its own storage, its own auth token provisioned from the phone during setup. That's the right choice for running, cycling and swimming products. It costs more than a companion app and it's the difference between a watch app athletes use and one they delete.
Why is our heart rate data sparse outside workouts?
Because outside an active workout session the watch samples ambient heart rate on its own schedule to preserve battery, and your app is notified of what lands in HealthKit rather than reading the sensor. Continuous high-frequency heart rate requires a workout session, which is exactly what workout sessions exist to enable.
Do complications update in real time?
No. You supply a timeline of entries and the system decides when to reload it, within a limited refresh budget. Design the complication to be useful when slightly stale, and never show a number that looks live when it isn't.
Should we build for Wear OS at the same time?
Usually not simultaneously. The platforms share no code, the sensor and background models differ, and Android health data flows through Health Connect rather than a direct watch framework. Ship one, learn whether wrist engagement is real for your audience, then decide. Tell us your user split and we'll tell you which one, and whether you need either yet.