Background Execution on Apple Watch: Two Mechanisms

The wrist is down for most of any real session. That is not an edge case to handle later; it is the normal operating condition of a watch app, and it is why background execution is an architecture question on watchOS rather than a polish item.

Apple documents two mechanisms. They are not interchangeable, they are not a fallback pair, and which one your app is allowed to use is decided by what your app does — not by how badly you need the runtime.

Mechanism one: an active workout session#

If your app is a training app, the workout session is the answer. Apple documents that HKWorkoutSession supports background execution while the device is locked, along with mirroring the workout to a companion iPhone, Live Activities on the Lock Screen, and Siri control for start, pause, resume and cancel.

The runtime comes attached to the thing you were building anyway. You do not request background time as a separate favor; you run a workout session, and the session is the reason the app keeps running. The object-level detail of that session — the builder that accumulates the sample, the state transitions, the exclusivity rule — is in the anatomy of a watchOS workout app.

One constraint travels with it. Apple documents that Apple Watch runs one workout session at a time, and that a second workout starting will end yours. Your background runtime therefore ends when the session does, including when the session ends for reasons that had nothing to do with your app.

Mechanism two: WKExtendedRuntimeSession#

For everything that is not a workout, Apple provides extended runtime sessions. The abstract is "A session that continues to run your app after the user has stopped interacting," and the capability description is specific about what you keep: "With extended runtime sessions, your app continues to run after the user stops interacting with it. The app can continue to communicate with Bluetooth devices, process data, or play sounds or haptics, even after the watch's screen turns off."

Bluetooth, processing, sound and haptics after the screen goes dark is exactly the capability set a guided experience needs — a breathing exercise that has to cue the next inhale, a rehab protocol that has to buzz at the end of a hold, a session driven by a paired sensor. Apple introduced the API in watchOS 6.0.

The lifecycle is small: a session has an expirationDate, is started with start() or start(at:), and is ended with invalidate(). Read expirationDate as a design input rather than a formality — the session is finite, and an experience that has no defined end will eventually run into one that the system chose for it. Decide what your app does when the runtime expires mid-protocol, and make that behavior something a user can understand rather than a silent stop.

The four types, and the one that is missing#

Apple states the selection rule directly: "Each app can support a single type of extended runtime session: self care, mindfulness, physical therapy, or smart alarm. Select the session by enabling the appropriate Background Modes capability."

There is no workout type in that list, and that is not an oversight. Workouts have their own mechanism in HKWorkoutSession, so Apple did not duplicate the capability under extended runtime. Stating it plainly because it saves a wasted afternoon: if you are building a training app, do not go looking for a workout background mode to enable — run the workout session. If you are building a rehab, breathing or mindfulness product, do not try to declare a workout you are not really running in order to borrow its runtime; pick the extended runtime type that honestly matches the experience.

The other half of that quoted sentence is a product constraint people miss on first read: one type per app. An app that wants to deliver strength training and guided meditation and a physical-therapy protocol has to choose which of the non-workout categories it declares, because it only gets one. That is a scoping decision to make early, not a build-setting to fix late, and for some product plans it is an argument for shipping two apps.

What both mechanisms have in common#

Whichever path you are on, the runtime is granted and can be taken away, and your app is the thing that has to behave well when it goes. Three habits are worth building in from the start.

Treat the end of runtime as a state, not an exception. The screen after a session ends unexpectedly is a real screen with real copy, and it should say what happened rather than freezing on the last value it had.

Persist as you go. Anything you would be sad to lose should already be written down before the runtime ends, because the moment the runtime ends is a bad moment to start doing work.

Instrument the endings. Log why each session ended and how much of the intended protocol completed. The ratio of user-initiated endings to everything else is the most useful health metric a watch app has, and it is the one nobody adds until after the support tickets. The general pattern is in data quality monitoring.

The phone is not a substitute#

It is tempting to solve watch runtime by pushing the work to the phone, and sometimes that is right — but a mirrored session is a division of labor, not an escape from the wrist's rules; see mirroring workouts to iPhone. Background behavior on the phone side has its own budget and its own throttling, which is background sync testing territory. Neither one gives a watch app permission to keep running that it did not otherwise have.

Verify before you ship#

Background behavior is the area of watchOS most likely to have moved since anything you read, including this page. Confirm the capability list and the session semantics against Apple's current documentation for your deployment target, and confirm the behavior itself on hardware — a simulator will not tell you what happens when a real wrist drops. What App Review expects of a given background mode declaration is not something we can state from the documentation we read, so treat that as worth confirming too.