WorkoutKit: Scheduling Workouts Into Apple's Workout App

Most coaching products have the same delivery problem. You have written somebody a program; they have to remember your app exists, open it, find today's session, and keep it in front of them while they train. Every one of those steps loses people.

WorkoutKit is Apple's answer to a version of that problem. Apple's abstract for the framework is one line: "Create, preview, and sync workout compositions to the Workout app." The last four words are the interesting part, because they mean your program can arrive somewhere the user already goes.

Four composition types#

Apple documents four ways to describe a workout, and the descriptions are worth quoting because each one implies a different kind of coaching product:

Read that list as a compatibility check on your product rather than a menu. If your programs are intervals with per-step targets, the custom type maps cleanly. If you coach a single daily target, the single-goal type is a two-line description of your whole product. If you write triathlon programs, the fact that transitions are modelled for you is a meaningful saving. If your programming is something the list does not describe — a strength session in sets and reps at prescribed loads, for instance — then a composition is not a faithful representation of it, and forcing the fit will produce a worse experience than keeping that programming in your own app. That judgement is ours; Apple's documentation only tells you what the types are.

WorkoutPlan and openInWorkoutApp()#

Compositions are carried by WorkoutPlan, which Apple documents as the object you use to preview workouts or open them in the Workout app via openInWorkoutApp().

This is the low-commitment entry point, and it is a reasonable first shipment. The user is in your app, taps the session you wrote for them, and lands in Apple's Workout app with that workout loaded. You did not build a watch training UI, you did not manage a session lifecycle, and the workout runs in the place the user already trusts for exactly this.

The trade is control, and it is a real one. Everything your own watch app would have shown — your form cues, your coaching copy, your branding during the work — is not there. Whether that trade is right depends on whether your differentiation is in the programming or in the in-session experience.

Scheduling: your program lands before the user opens anything#

The scheduling API is the part that changes the product rather than the plumbing. Apple describes it as the ability to "Create and maintain a workout schedule and, with the user's permission, sync scheduled compositions to Apple Watch," and then states the payoff: "These compositions appear in a dedicated space in the Workout app and include your app's icon and name."

Two things are worth pulling out of that sentence. The scheduled workout appears without your app being opened, and it is attributed to you — icon and name — in Apple's own interface. For a coaching business, that is presence on the device between sessions, which is normally the hardest thing to buy.

The mechanics are a permission and a call: WorkoutScheduler.requestAuthorization() to ask, and WorkoutScheduler.schedule(_:at:) to place a composition at a time. Treat the authorization as the product moment it is. A user who has just been sold on "your program will be waiting on your watch" will grant it; a user who gets the prompt during a cold first launch, before they have a program at all, mostly will not.

"Create and maintain" also implies the unglamorous half of the work. Plans change: a coach moves Thursday to Friday, a user goes on holiday, an injury rewrites the week. Whatever you schedule is state you now own in two places, so decide early which side is authoritative and how a change propagates. Our judgement is that your backend should hold the plan and the device schedule should be a projection of it, refreshed on a defined trigger, rather than a second copy that drifts.

Platform floors and what you do below them#

Apple lists WorkoutKit availability from iOS, iPadOS and Mac Catalyst 17.0, and watchOS 10.0. Below those versions the feature does not exist, so if your deployment target reaches back further you need a path that does not depend on it — which, for in-session experiences, means your own watch app and the session spine in the anatomy of a watchOS workout app.

What WorkoutKit does not replace#

Composing and scheduling a workout is not the same as running one. When the workout is executing, the live behavior — sensor tuning for the declared activity, high-frequency heart rate, background execution, exclusivity — belongs to the workout session mechanism, which is where every in-session concern still lives, including background execution.

How completed scheduled workouts flow back into your product is a question we would not answer from the documentation we read this session. Verify the round trip against current Apple documentation before you design a feature that depends on it, and remember that results landing in HealthKit is its own read path with its own authorization behavior — see HealthKit on Apple Watch and the HealthKit integration guide — plus the usual reconciliation work in deduplicating health data.

How to sequence this#

A pragmatic order, offered as judgement rather than as Apple guidance. Ship openInWorkoutApp() first: it is small, it proves your compositions are faithful to your programming, and it puts a real workout in front of users quickly. Add scheduling second, once you know your plan model is stable enough that what lands on the watch will not need constant correction. Build your own watch app third, and only if the in-session experience is genuinely part of what you sell — because at that point you are taking on the whole lifecycle, and the reminder cadence that used to live in push notifications starts competing with a surface Apple already gave you.