Wear OS Exercise Tracking with Health Services (2026)

A watch app that tracks workouts is a state machine wrapped around a platform service. On Wear OS 3 and later that service is Health Services, and Google describes it as an intermediary between apps and the device's sensors and algorithms. You do not open sensors; you ask for an exercise and consume what comes back.

This page is about the app side of that arrangement: how the exercise shapes your code. The sensor-source question — what Health Services is, and when a Bluetooth device is the better origin for a signal — is covered in Wear OS Health Services.

ExerciseClient is a lifecycle, not a data feed#

Google's documentation describes ExerciseClient as the API for managing workouts, setting exercise goals, listening for exercise state updates, and receiving rapid data updates during active exercise. The metrics it lists are "heart rate, distance, calories, elevation, floors, speed, pace, and more."

Four capabilities, and only one of them is the data stream everyone thinks of first. Taken together they say something about how the app should be built:

Managing the workout is the platform's job, not a flag in your view model. The exercise exists in Health Services. Your app is a subscriber to something the system owns, which is why the next point matters so much.

Exercise state updates are the source of truth for your UI state. If your screen has its own idea of whether a workout is running, and Health Services has another, the two will disagree eventually — after a process death, after the user interacts with something else, after any event you did not anticipate. Our judgement, and it is the single most useful structural rule on this page: drive the UI from the exercise state you are told about, and never from a boolean you set when the user tapped start.

Rapid data updates are a property of being in an exercise. The high-frequency path is not a mode you request; it is what an active exercise gives you. That is the same bargain watchOS makes with a workout session.

Exercise goals are tracked for you. You can set a goal and be told when it is met instead of comparing numbers on every tick.

Let the platform own the goals#

The goal capability is easy to skip past, because every team already has code that compares a distance to a target. Our judgement is to delete that code where a documented exercise goal covers the case. Two reasons: a goal evaluated by the platform is evaluated against the platform's own numbers, so a "5 km reached" event cannot disagree with the distance shown on the screen; and a goal you evaluate yourself only fires when your code is running to evaluate it, which is a much weaker guarantee than it looks on a device that aggressively puts things to sleep.

Keep your own logic for what the platform does not model — interval structure, coaching cues, set and rep counting — and build it on top of the exercise rather than beside it.

The other client, and what it is for#

PassiveMonitoringClient is the counterpart. Google's documentation describes it as the way to receive updates about a data type or an event, and says it "is suited for long-lived experiences where data updates are relatively infrequent."

That sentence is the boundary. Anything ambient — a step total behind a tile, an all-day trend, an event you want to react to — belongs on the passive path. An exercise session is for an exercise the user started. Holding one open to keep an ambient surface warm is the classic way to make a watch app unwelcome.

What you get, and what you give up#

Google makes two claims about Health Services that are worth treating as design constraints rather than marketing copy. It "conserves battery by using sensor configurations from Health Services that are optimized for power efficiency" — sensor configuration is the platform's decision, tuned for the exercise type, and it is not yours to override. And it "verifies data consistency across all applications on the same device by using standardized platform computations."

Standardized computation is the part with real product consequences. It means two apps on the same watch report the same calories for the same run, so a user never has to decide which of your two competitors is lying. It also means the derived metric is the platform's answer, not yours. If a differentiated metric is your product, you are building it on top of a shared foundation and should know that going in. We publish no figures for any of this; the claims above are Google's, stated as design properties rather than measurements.

When the signal is not on the wrist#

Health Services covers what the watch can sense. It cannot invent hardware. A chest strap the user already owns is a standard Bluetooth Heart Rate service connection and behaves identically whether the central is a watch or a phone — see Bluetooth heart rate monitors. The same is true for cycling and gym-equipment sensors. Whether you can run an exercise session and a direct sensor connection together in a way that satisfies your accuracy expectations is a question for a real device and a real workout, not for a docs page.

One data-modelling rule survives either path: record which source produced a sample. A wrist optical reading and a strap reading are different measurements, and merging them into one undifferentiated series is a modelling error that surfaces later as a support ticket. Deduplicating health data covers the reconciliation side.

Where this sits in the watch app#

The exercise is the engine; three other pieces surround it. Keeping the app on screen while a workout runs belongs to Wear OS Ongoing Activity, which owns that topic on this site. Getting the user into the workout in one tap belongs to tiles. Getting the finished workout to your backend belongs to phone sync — and the short version is that the watch should talk to your server directly.

Finally, decide early whether the app is standalone, because an exercise loop that runs entirely on the watch is the strongest argument for saying yes. Wear OS app anatomy covers that decision and the manifest value that carries it.