Does an HKWorkoutSession give higher-frequency heart rate than reading HealthKit samples on Apple Watch?

Yes, and Apple states it directly: all workout sessions generate high-frequency heart rate samples. Apple also documents that the session fine-tunes Apple Watch's sensors for the activity type you declare, which is why the declared activity is a real input rather than a label. There is no equivalent query parameter on the store side. HealthKit is where samples are persisted and queried, so polling it more aggressively does not raise the rate at which the watch produces them. If your product needs a number that updates while somebody is mid-interval, the session is the mechanism, and the store is where the record lands afterward.

What happens to my watchOS workout session if the user starts a workout in Apple's Workout app?

Yours ends. Apple documents that Apple Watch runs one workout session at a time, and that if a second workout starts while your workout is running, your session ends. Treat that as an ordinary state transition rather than an error. In practice it means your live screen must be able to say that data has stopped instead of leaving the last received value on screen to age silently, and any recording you were doing needs a defined close-out path. It also affects onboarding: if users are likely to run more than one fitness app during a gym session, you are competing for the single slot rather than sharing it.

Can an Apple Watch workout session keep running while the watch is locked and show data on iPhone?

Both are documented capabilities of workout sessions. Apple lists background execution while the watch is locked, mirroring the workout to a companion iPhone, and starting, pausing, resuming or canceling the session with Siri. Background execution while locked is what makes a usable workout app possible, since a wrist that has gone to sleep is the normal case during exercise. Mirroring lets the phone act as the large display while the watch remains the sensor. Plan for Siri control specifically, because it means session state can change from outside your own interface, so your view has to follow session state rather than assume it drives it.

Connected Devices

Live Heart Rate From Apple Watch in Your App (2026)

Last verified August 14, 2026 · 5 min read

HealthKit is a store, not a live stream, so polling it harder will not give you a number that updates while somebody is mid-interval. On Apple Watch the live path is a workout session: Apple documents that a session fine-tunes the watch's sensors for the activity you declare, and that all workout sessions generate high-frequency heart rate samples. HKWorkoutSession is available from watchOS 2.0, and Apple also lists iOS, iPadOS and Mac Catalyst 17.0 and visionOS 1.0. Apple Watch runs one session at a time, so a second workout started elsewhere ends yours, which makes session-ended a normal state your UI has to handle. If you need heart rate without requiring an Apple Watch at all, pair a Bluetooth strap directly and read the standard Heart Rate service instead.

View as MarkdownPost Hacker News Reddit LinkedIn

Covered here:HealthKit

Most teams arrive at this question having already tried the obvious thing. They read heart rate out of HealthKit, watch the numbers land late and in clumps, and conclude that the watch sensor is slow. It isn't. They are reading the wrong surface. HealthKit is where health data is stored and queried; the live path on Apple Watch is a workout session, and those are different APIs with different jobs.

What the store is for, and what it isn't for#

HealthKit is excellent at the things a store should be good at: history, authorization, cross-app sharing, rollups over a week. It is the wrong shape for a screen that has to redraw a number every couple of seconds while somebody is holding a plank. If you are building the history half of the product, the HealthKit integration guide covers setup and permissions and heart rate APIs covers what the data looks like once you have it. This page is about the other half, and the distinction is the single most useful thing to get straight before you design anything.

The workout session is the live path#

Apple's abstract for HKWorkoutSession is one sentence: "A session that tracks a person's workout." The behavior that matters for live data is in the surrounding documentation, and it is unusually explicit. Apple writes that "the session fine-tunes Apple Watch's sensors for the specified activity," and then, in the sentence worth hanging your architecture on: "All workout sessions generate high-frequency heart rate samples; however, an outdoor cycling activity generates accurate location data, while an indoor cycling activity doesn't."

Two consequences fall out of that. First, high-frequency heart rate is a property of being in a session, not of asking HealthKit more often. There is no query parameter that substitutes for it. Second, the activity type you declare is not a label for the summary card at the end — it is an instruction to the sensor stack about what to spend power on. Declaring indoor cycling for an outdoor ride is not a cosmetic mistake.

Apple lists availability as watchOS 2.0 and later, with iOS, iPadOS and Mac Catalyst from 17.0 and visionOS from 1.0. Our reading of that spread, offered as judgement rather than as an Apple statement: the watch is still where the sensors are, and the newer platform availability matters mostly for the phone side of a mirrored session rather than as an alternative source of wrist heart rate.

One session at a time, and what that does to your state machine#

Apple is direct about the exclusivity rule: "Apple Watch runs one workout session at a time. If a second workout starts while your workout is running, your session ends."

Design for that sentence rather than around it. Your session can terminate for reasons that have nothing to do with your UI — the user starts a run in Apple's own Workout app, or opens a different third-party app and taps start there. So "session ended" is an ordinary state, not an error state, and the honest thing to show is that live data stopped, not a frozen last value that quietly ages on screen. Teams that treat termination as exceptional tend to ship a screen that displays a two-minute-old heart rate with no indication that it is stale.

The same rule shapes onboarding. If your app is one of several a user might run during a single session in the gym, you are competing for a slot rather than sharing one, and it is worth saying so in the interface before the user discovers it mid-workout.

Locked, mirrored, and voice-controlled#

Apple documents three further session capabilities that change what you can build: sessions support background execution while the watch is locked, they can mirror the workout to a companion iPhone, and they can be started, paused, resumed and canceled through Siri.

Background execution while locked is the one that makes a real workout app possible at all — a wrist that has dropped to sleep is the normal case during exercise, not an edge case. Mirroring is what lets the phone be the big screen while the watch stays the sensor. Siri control is worth planning for because it means state changes can originate outside your own UI, which is the same lesson the exclusivity rule teaches: your session state is authoritative, your view is downstream of it.

The other route: pair a strap directly#

A workout session ties your live heart rate to Apple Watch. The alternative is to skip the watch and connect a Bluetooth Low Energy heart rate sensor from the phone, reading the SIG-standard Heart Rate service (0x180D) with its Heart Rate Measurement characteristic (0x2A37) and the optional Body Sensor Location characteristic (0x2A38). The mechanics of that are in Bluetooth heart rate monitors, and the iOS framework side is in Core Bluetooth for fitness devices.

The trade is structural, not a matter of one being better. A workout session requires the user to own and wear an Apple Watch, and gives you Apple's sensor tuning, background behavior and mirroring for free. A direct BLE connection works for users with no watch, uses the same standard profile on Android and in the browser, and puts you in charge of pairing, reconnection and parsing. If you need one implementation that serves iPhone, Android and a gym kiosk, the strap path is the one that ports; Wear OS Health Services is the equivalent watch-native path on the other platform.

On which one reads better: placement and sensor type differ between a wrist optical sensor and a chest strap, and we are not going to publish accuracy numbers for either. Measure it for your own use case, with your own population and your own activity mix, before you make a claim in your marketing.

What to instrument#

Whichever path you take, treat the live stream as a data source that can degrade quietly. Log session start and end with the reason, log gaps between samples, and watch the rate at which sessions end without a user-initiated stop — that number is your best early signal that something in the app or the OS is interrupting you. Data quality monitoring covers the general pattern, and mocking wearable data covers building fixtures ugly enough to catch the interruptions before your users do.

Frequently asked questions

Does an HKWorkoutSession give higher-frequency heart rate than reading HealthKit samples on Apple Watch?: Yes, and Apple states it directly: all workout sessions generate high-frequency heart rate samples. Apple also documents that the session fine-tunes Apple Watch's sensors for the activity type you declare, which is why the declared activity is a real input rather than a label. There is no equivalent query parameter on the store side. HealthKit is where samples are persisted and queried, so polling it more aggressively does not raise the rate at which the watch produces them. If your product needs a number that updates while somebody is mid-interval, the session is the mechanism, and the store is where the record lands afterward.
What happens to my watchOS workout session if the user starts a workout in Apple's Workout app?: Yours ends. Apple documents that Apple Watch runs one workout session at a time, and that if a second workout starts while your workout is running, your session ends. Treat that as an ordinary state transition rather than an error. In practice it means your live screen must be able to say that data has stopped instead of leaving the last received value on screen to age silently, and any recording you were doing needs a defined close-out path. It also affects onboarding: if users are likely to run more than one fitness app during a gym session, you are competing for the single slot rather than sharing it.
Can an Apple Watch workout session keep running while the watch is locked and show data on iPhone?: Both are documented capabilities of workout sessions. Apple lists background execution while the watch is locked, mirroring the workout to a companion iPhone, and starting, pausing, resuming or canceling the session with Siri. Background execution while locked is what makes a usable workout app possible, since a wrist that has gone to sleep is the normal case during exercise. Mirroring lets the phone act as the large display while the watch remains the sensor. Plan for Siri control specifically, because it means session state can change from outside your own interface, so your view has to follow session state rather than assume it drives it.

Keep reading

Elsewhere on the site

Pages that share this one’s concepts and sources, from other sections.

Next steps

Was this page useful?

Suggest a correction

Independent comparison, last reviewed August 14, 2026. Pricing, rate limits, and feature availability change often — confirm current details in each provider’s official documentation before you commit. Product and company names are trademarks of their respective owners; AIFitnessAPI is not affiliated with, endorsed by, or sponsored by any product listed here.

← All connected devices · by AIFitnessAPI