Live Activities for Workout Tracking on iOS

A Live Activity is the iOS surface for something that is happening right now and will keep happening for a while. Apple's ActivityKit documentation describes the framework as a way to "share live updates from your app as Live Activities on iPhone, iPad, Apple Watch, and the Mac," and states the purpose plainly: Live Activities "offer a rich, interactive, and highly glanceable way for people to keep track of an event or activity over several hours, especially for apps that push the limit of notifications to provide updated information."

Read that last clause as a diagnosis. If your in-progress workout experience is currently held together by repeated notifications, you are the app the framework was written for.

The surfaces you get for one implementation#

Apple documents Live Activities appearing on the iPhone and iPad Lock Screen, in the Dynamic Island, and on the Home Screen; in the Apple Watch Smart Stack; in the Mac menu bar; and on the CarPlay Home Screen.

That list is most of the argument for building one. A workout in progress is exactly the state a user wants to check without unlocking anything, and on the Watch Smart Stack it appears on the device already strapped to the arm doing the work.

One exclusion is documented explicitly: "visionOS doesn't support Live Activities. Requests to start a Live Activity from a compatible iPad or iPhone app fail." If your iPad app runs on Vision Pro, that is a failure path to handle rather than a surface to plan for.

Two update paths, and one of them can start the activity#

Apple documents the update model in a single sentence worth unpacking: "Live Activities receive updated data from your app with ActivityKit and from your server with ActivityKit push notifications, and you can start Live Activities with ActivityKit push notifications."

That is three separate capabilities.

Updates from the app cover state your app owns while it is running: elapsed time, the current interval, the set you are on.

Updates from your server via ActivityKit push notifications cover state that arrives from elsewhere: a coach's change to today's plan, a partner finishing their leg of a shared session, a result reconciled on the backend after a device sync.

Starting an activity from a push is the architecturally interesting one, because it means the live surface does not depend on the app being in the foreground at the moment the event begins.

Unlike widgets, Live Activities do not use the timeline mechanism. A widget hands WidgetKit a timeline of future states; a Live Activity is updated as reality changes. Do not carry the timeline mental model across — see widgets and complications for the side that does use one.

Interaction without launching the app#

Apple documents that "people perform essential functionality without launching your app using buttons or toggles included in a Live Activity layout or tap the Live Activity to launch the app to a scene that matches the activity's content."

For a workout, the essential functionality is pause, resume, skip and next set. The second half of that sentence is the part teams skip: the tap target should deep link into the scene matching the activity, not into your home tab. A user who taps a running workout and lands on a promotional carousel has been punished for using the feature.

Why a workout is close to the ideal case#

Apple's framing is an event with changing state over several hours. A workout satisfies that better than most of what people build Live Activities for.

It has a definite start and a definite end, both known to your app. Its state changes continuously and meaningfully rather than once an hour. The user is physically occupied and often cannot hold a phone at all. And the ending is unambiguous, which matters more than any of the rest, because the worst Live Activity is one that outlives the thing it describes.

That last point is the one to design first. Decide what ends the activity — user stops, session completes, the app is terminated, the session goes stale with no incoming samples — before you decide what any of it looks like.

Live data does not come from HealthKit#

This is where fitness teams lose the most time. HealthKit is a store, not a live stream. Polling it in a loop to drive a Live Activity is the wrong shape, and the result feels like it.

Live in-workout data on Apple platforms comes from a workout session, which is the mechanism designed to deliver samples while the workout is actually happening. Apple Watch live heart rate covers how that side is assembled, and HealthKit integration covers what belongs in the store instead. The clean architecture is three responsibilities in three places: the workout session produces live state, your app pushes that state into the Live Activity, and the store receives the finished session afterward. No polling anywhere in that sentence.

For sensors that are not an Apple Watch, a Bluetooth heart rate monitor feeds the same live-state layer directly, and the Live Activity does not need to know which source won.

What to decide before you write any of it#

The content model. A Live Activity has a small, fixed vocabulary of state. Make it an explicit projection of your session model rather than an ad-hoc struct that drifts away from it over three releases.

The failure states. What is displayed when the strap drops, the phone loses the watch, or your backend is unreachable. A frozen number reads as a live number, and that is worse than admitting the value is currently unknown.

The end condition. Write it down first, as above, and make sure every terminal path calls it.

The Android answer. There is no equivalent framework to port to. The nearest analogue on the watch is Wear OS ongoing activity, which is built out of an ongoing notification rather than a dedicated framework and therefore inherits Android's notification permission rules. Treat the two as parallel implementations of one product idea, not one feature with two SDKs.

Verify the framework details against Apple's current ActivityKit documentation before building. Surfaces and capabilities here have moved with almost every release, and this page states what Apple documents as of its review date.