Most "this animation feels off" bugs are not timing bugs. They are one of four category errors: bounce on something nothing threw, motion that ignores the gesture that caused it, an animation that restarts from the wrong value when interrupted, or feedback that arrives after the user already let go. Fix the category first; only then argue about the number.
The one table that decides damping
Bounce is earned by momentum. If the user threw it, it overshoots. If the user tapped it, it does not. This single rule resolves most spring arguments.
| Interaction | Damping | Response |
|---|---|---|
| Tap-driven — buttons, toggles, selection, panels opened by a button | 1.0 (critically damped) | 0.3–0.4s |
| Momentum-driven — flicks, throws, drag release | 0.8 | 0.3–0.4s |
| Move / reposition | 1.0 | 0.4s |
| Rotation | 0.8 | 0.4s |
| Drawer / sheet | 0.8 | 0.3s |
A tap-opened drawer takes damping 1.0, not the 0.8 in the drawer row — the row assumes the drag-to-open drawer it was measured on. Read the trigger, not the component name.
Symptom mapping: wobble on a tap means damping too low, not duration too long. Sluggish is usually response too high, not damping. Cheap/mechanical is usually a linear or ease-in-out curve where a spring belongs.
SwiftUI's presets, in the terms above
| Preset | Damping | Use |
|---|---|---|
.smooth |
critically damped, no overshoot | the default for tap-driven UI |
.snappy |
slightly underdamped, small overshoot | brisk feedback, small elements |
.bouncy |
low damping, visible oscillation | playful, deliberate character |
All three default to duration: 0.5; all take duration: and extraBounce:. Reach for a preset
before a hand-rolled .spring(response:dampingFraction:) — a named preset states intent, and
0.34/0.82 states nothing.
With the modern .spring(duration:bounce:) form, bounce is the readable axis:
| bounce | Reads as |
|---|---|
0.0 |
critically damped, smooth arrival |
0.15 |
brisk, not bouncy |
0.2 |
drag release with velocity |
0.3 |
exaggerated, deliberate |
> 0.4 |
extreme — wrong for almost all UI |
< 0 |
overdamped, flatter than critical |
Start at bounce: 0 and add only if the motion has momentum to justify it.
Gesture-driven motion
This is where "premium" is actually won, and where duration tuning cannot help you.
Respond on pointer-down, not on release. An interaction that only animates after the gesture ends feels dead during the part the user is actually looking at.
Track 1:1 during the gesture. The view follows the finger frame by frame. No easing, no smoothing, no animation context — the user is the animation.
Hand the release velocity to the spring. A spring that starts from zero velocity after a fast flick visibly stalls. Normalized relative velocity:
relativeVelocity = gestureVelocity / (targetValue − currentValue)
Project the resting point with exponential decay, then snap to the nearest target and hand off
velocity — not the textbook v² / 2a:
func project(initialVelocity: Double, decelerationRate: Double = 0.998) -> Double {
(initialVelocity / 1000) * decelerationRate / (1 - decelerationRate)
}
Rubber-band at boundaries, never hard-stop. Resistance should grow progressively past the edge.
Interruptibility
Never start an animation from its target value. Read the live on-screen presentation value, or an interrupted animation visibly jumps. SwiftUI springs animate from the current value by default — which is precisely why hand-rolling a morph with keyframes or timers is worse than it looks.
Never lock out input while animating. .allowsHitTesting(false) across an animating region
needs a stated reason. Springs retarget for free; a user who changes their mind mid-animation
should be obeyed, not queued.
One animation source per property. Never mix implicit .animation, withAnimation, and
gesture-driven updates on the same value — an implicit modifier later in the view tree silently
wins over an explicit withAnimation, and the resulting fight is invisible in code review.
The animation context lives outside the conditional. An .animation() written inside an if
is destroyed along with the view, so removal never animates. Put it on a view that survives the
change, or use withAnimation at the mutation site.
Ordering
Animate in this order of cost and reliability: transforms (scale, offset, rotation) first, frames second, identity changes last. A transform is cheap and interpolates exactly; a frame change forces layout; an identity change cannot interpolate at all and gives you a cut.
Corollary: a "morph" between two mutually exclusive views is an identity change and will not interpolate. Morph one persistent view whose properties animate, rather than swapping two.
Consistency beats correctness
Three selection controls that each animate at a different speed read as sloppy even when every
individual value is defensible. Name the animation once in a design system and reference it;
a bare withAnimation { } means nobody chose, and it will not match the sibling that did.
If you find the same interaction animating three ways, the finding is the inconsistency — fix it by adopting whichever value was deliberately authored, not by inventing a fourth.
Accessibility is part of the feel
Every app-authored animation needs a Reduce Motion branch — the system tones down its own motion,
never yours. Substitute, do not remove: a state change with no feedback is harder to follow.
Crossfade → shortened (0.1–0.15s, no bounce) → instant, in that order of preference. Gesture
tracking stays; only the release spring is tamed. Full treatment, including glass specifics, is in
the liquid-glass-motion skill's reduce-motion.md.
Verify
# Magic numbers that state no intent — candidates for a named preset
grep -rn "\.spring(response:\|dampingFraction:" --include="*.swift" .
# "Nobody chose" — bare withAnimation next to siblings that did choose
grep -rn "withAnimation {" --include="*.swift" .
# Animation contexts trapped inside conditionals
grep -rn -B3 "\.animation(" --include="*.swift" . | grep -A3 "if "
Sources
The damping/response table, the velocity-handoff formula, the momentum-projection function, and
the gesture do-nots are adapted from emilkowalski/skills — apple-design.
The bounce bands are from GetStream/swiftui-spring-animations.
Interruptibility and preset semantics are checked against Apple's WWDC23 sessions
Animate with springs and
Wind your way through advanced animations in SwiftUI.
Checklist
- Damping follows the trigger: 1.0 for tap, 0.8 for momentum — not the component's name.
- Response sits in 0.3–0.4s unless there is a reason on the line.
- A named preset (
.smooth/.snappy/.bouncy) is used where it states the intent. -
bounce > 0.4appears nowhere. - Gestures respond on pointer-down and track 1:1; release velocity is handed to the spring.
- Boundaries rubber-band; nothing hard-stops.
- No animation starts from its target value; nothing locks out input while animating.
- One animation source per property; the context lives outside any conditional.
- The same interaction animates the same way everywhere, from one named constant.
- Every authored animation has a Reduce Motion branch that substitutes rather than removes.