What an Apple Watch app really adds to a workout

The value is heart rate and calories

Without the watch, the calorie line stays empty for HIIT, and a strength workout only reaches Apple Health as an estimate: MET value 5.5 × body weight × hours. With the watch, estimates turn into measurements, and they show up everywhere. Live on the iPhone, for HIIT also in the Live Activity and the Dynamic Island, for runs at every GPS point and as average heart rate per kilometer.

At the end, the watch saves the workout to Apple Health with measured values. For strength training only the watch saves it, otherwise the same workout would show up twice.

On the wrist, what works without looking counts

The workout starts on the iPhone, then the watch takes over. Strength training gets one page per exercise, weight in 2.5 kg steps and a button to check off a set; HIIT gets countdown, round and heart rate; runs get pace, distance and interval cues. A checked-off set, the start and the end of a rest all vibrate, so you feel the rest instead of staring at your wrist.

The iPhone records the route, and the voice coach speaks from the iPhone too. Its kilometer announcements, however, report heart rate and calories from the watch.

One workout session is enough for the measurements

The measuring part is pleasantly short. An HKWorkoutSession puts the watch into workout mode, an HKLiveWorkoutBuilder collects the values. NOXA takes the latest heart rate and the sum of active calories and sends both to the iPhone every five seconds.

let config = HKWorkoutConfiguration()
config.activityType = .traditionalStrengthTraining
let session = try HKWorkoutSession(healthStore: store, configuration: config)
let builder = session.associatedWorkoutBuilder()
builder.dataSource = HKLiveWorkoutDataSource(healthStore: store,
                                             workoutConfiguration: config)
session.startActivity(with: .now)
try await builder.beginCollection(at: .now)

The connection to the iPhone was the real work

WatchConnectivity offers several channels, and each has its own personality. sendMessage is immediate, but only if the watch is reachable right now. updateApplicationContext keeps the latest state ready, even with the display off. transferUserInfo delivers guaranteed, later if need be. That's why the iPhone sends the workout start over all three.

The rest we learned in production. Too many sendMessage calls end in timeouts, so ongoing updates go into the application context. A push from the iPhone didn't always arrive, the other direction did; since then the watch asks for itself, with at most one open request. And the transferUserInfo queue filled up over weeks until the connection got sluggish. Old transfers now get thrown out.

Timestamps keep zombie workouts away, meaning workouts that reappear after they've ended: at app launch the watch only takes over a state younger than two hours, on wake-up only one younger than five minutes.

What we take away

The iPhone is the source of truth. The watch keeps the workout state in memory only and fetches it from the phone after a restart.

Every channel has a job. Immediate message for the reaction, application context for the latest state, queue for what must not get lost. And the queue needs regular cleaning.

The value is in the data, not the display. Heart rate and calories only become useful once they end up in splits, logs and Apple Health. More about the app on the NOXA page.