Reduce Motion in a coaching interface

A coaching app is mostly motion. The exercise demonstration loops forever in the corner. The pose overlay redraws every frame. The countdown ring sweeps, the rest timer pulses, the header parallaxes as you scroll the programme, and a personal record fires confetti across the summary. Strip the animation out of a coaching product and there is surprisingly little left, which is exactly why Reduce Motion is a harder setting for this category than for almost any other.

What Apple asks for#

Apple's Human Interface Guidelines are unusually direct about the stakes:

"Be cautious with fast-moving and blinking animations. When you use these effects in excess, it can be distracting, cause dizziness, and in some cases even result in epileptic episodes. People who are prone to these effects can turn on the Reduce Motion accessibility setting. When this setting is active, ensure your app or game responds by reducing automatic and repetitive animations, including zooming, scaling, and peripheral motion."

Two phrases in that paragraph do the work for a coaching app. Apple's "automatic and repetitive" describes a demo loop precisely, and "peripheral motion" describes everything moving at the edge of a screen whose centre the user is trying to read mid-set. Apple's listed best practices also include "Tightening animation springs to reduce bounce effects", which is the cheapest change on this whole page.

Apple documents the property for reading it plainly: UIAccessibility.isReduceMotionEnabled is "A Boolean value that indicates whether the Reduce Motion setting is in an enabled state."

if UIAccessibility.isReduceMotionEnabled {
    // no confetti, no parallax, no looping background
}

That is the whole API surface we verified for this, so that is all this page shows. Do not build a branch around a method name you half-remember; check Apple's reference page for the current surface.

Decoration or information: the only question that matters#

The mistake is treating Reduce Motion as a switch that deletes animation. Some of your animation is decoration and should go. Some of it is the product, and deleting it removes the teaching rather than the discomfort. Sort every animated element into one of the two buckets before you write any code.

The rule underneath the table: ask what the user loses if this element stops moving. If the answer is nothing, cut it. If the answer is a fact they need, you owe them another way to get that fact.

The demo loop is the hard case#

A looping video or animation of an exercise is not decoration. It is how the user learns where their elbows go. Removing it under Reduce Motion is the accessibility equivalent of removing the instructions.

Replace it instead. Four options, all judgement rather than platform guidance, and they compose:

A still frame at the position that carries the information — usually the end of the concentric phase, sometimes both extremes shown side by side, so the movement's range is visible without anything moving.

A user-driven scrubber. The user controls the motion, which means motion only happens when they ask for it, and it stops when they stop.

A play control instead of an autoplay loop. Same content, not automatic and not repetitive, which is the specific pair of words Apple's paragraph names.

A written description of the movement. Cheapest to build, useful to more people than this setting reaches, and the thing a coaching product should probably have anyway.

Our judgement: ship the still frame plus the play control as the baseline, because together they cover the case without a second content pipeline.

Pose overlays#

A skeleton drawn over live camera frames is not the same kind of thing as a parallax header. It moves because the user moves, it is not automatic, and its motion is the feedback. Apple's paragraph is about reducing automatic and repetitive animations; whether a live overlay falls inside that is a judgement we are making, not something the documentation we read answers.

What we would do: keep the skeleton, cut the flourish around it. Joint pulses, motion trails, easing on the landmark positions, a glow that animates when a rep is counted — those are decoration layered on data and they can all go. If your overlay is heavy on effects, offer a plain mode independently of the system setting, since a user who wants less motion in a camera view may not have Reduce Motion turned on. The motion cluster covers the tracking itself, and how form feedback works covers what the overlay is trying to say.

The wrist changes the answer#

A ring sweeping on a watch face is peripheral motion at very close range on a device that is already moving with the arm. The wrist is also where celebratory animation is most likely to fire during exercise rather than after it.

We did not verify anything watch-specific about Reduce Motion this session — the Apple paragraph quoted above is the guidance we have, and it is not written per platform. What we would carry across is the sorting exercise, applied harder: a watch screen has room for one thing, so if the animation is not the thing, it should not be there during a workout. The watch cluster covers what else changes on the wrist.

Android: a gap we are not going to paper over#

We could not verify Android's equivalent setting. The Google documentation we fetched this session contains no primary page describing an animation-scale or reduce-motion preference, so this page does not describe one, does not name an API for reading it, and does not tell you how to branch on it. Anything you read elsewhere that names one should be checked against Google's current documentation before it goes into your code.

There is a design answer that does not depend on resolving that. Make the behaviour available in your own settings, on both platforms: a switch that stops the demo loop autoplaying, turns off celebration effects, and drops the overlay to plain. Wire the system setting to it as an input where you have verified one, and let the user reach it directly where you have not. That also covers the users who want less motion but have never opened the accessibility settings. Building a home workout app is where most of these surfaces live, and celebration animation specifically is gamification territory.

Monday morning#

Turn Reduce Motion on and run one complete workout in your own app, from programme browse through the last set to the summary. Write down every animation you see. Sort the list into decoration and information, without arguing about the middle cases yet.

Ship the decoration cuts immediately, including the spring tightening Apple lists as a best practice. Then, for each informational animation, design the replacement rather than the removal: a frame, a control, a number, a sentence. Last, add the in-app toggle, because it is the only part of this that works on both platforms today.