The apple-design skill: fluid, physical UI on the web

Most AI-built UI moves like a slideshow. Something happens, a fixed animation plays, and you wait for it to finish before you can touch anything again. Apple's interfaces don't feel like that, and the reason isn't taste — it's a specific set of rules about how motion should behave. The apple-design skill packages those rules so Claude Code can build and review web UI that follows them.

It's a knowledge skill distilled from Apple's WWDC design talks — mostly Designing Fluid Interfaces (2018) — and translated into the web platform: Pointer Events, spring libraries,backdrop-filter, requestAnimationFrame. Here's how to install it and the handful of ideas that do most of the work.

The skill lives in Emil Kowalski's public skills repo. Point Claude Code at it and let it read the SKILL.md:

npx @anthropic-ai/claude-code skill install \
  https://github.com/emilkowalski/skills

Or just paste the repo URL into a session and tell Claude to absorb it for the current project. Either way, once it's in place the skill fires automatically whenever you're working on gesture-driven UI, spring animation, sheets and drawers, translucent materials, or typography — you don't have to invoke it by name.

Every rule in the skill serves a single sentence: an interface feels alive when motion starts from the current on-screen value, inherits the user's velocity, projects momentum forward, and can be grabbed and reversed at any instant. Read that again, because it explains why so much AI-generated motion feels off. A CSS @keyframes animation can't do any of those four things. A spring does all of them by default.

“The thought and the gesture happen in parallel.”

That's the standard the whole skill holds you to. If a user can touch it, they can change their mind about it mid-motion, and the interface has to keep up.

The skill covers seventeen sections, but four principles carry the feeling. Get these right and the rest is polish.

Notice the through-line: they all treat the user's hand as the source of truth. Where the finger is, how fast it's moving, where that motion is headed. The interface reads intent from the gesture instead of running a script.

This is the practical core. A fixed-duration animation is a prescription; a spring is a conversation. New input just moves the target and the motion stays continuous, which is exactly what interruption needs. Apple threw out the physics triplet (mass, stiffness, damping) for two parameters a designer can reason about:

• Damping ratio controls overshoot. 1.0 is critically damped — a smooth settle with no bounce. Below 1.0 overshoots and oscillates. Lower is bouncier.
• Response is how fast the value reaches the target, in seconds. This is not duration — a spring has no fixed duration, it settles when the physics settle.

The default that keeps you out of trouble: start everything at damping 1.0, and only add bounce when the gesture itself carried momentum. Overshoot on a menu that just faded in feels wrong. Overshoot on a card you flicked feels right. Here are the values Apple actually ships:

import { animate } from "motion"

// Default UI move — critically damped, no overshoot
animate(el, { y: 0 }, { type: "spring", bounce: 0, duration: 0.4 })

// Momentum interaction — slight bounce, only because a flick preceded it
animate(el, { y: target }, { type: "spring", bounce: 0.2, duration: 0.4 })

The skill shines on interactive pieces — a bottom sheet, a swipeable carousel, a drag-to-dismiss card. Give Claude Code the component and name the interaction. It pulls the right technique and the concrete numbers on its own:

Build a bottom sheet I can drag down to dismiss.

Follow the apple-design skill: 1:1 pointer tracking with the grab
offset respected, project the release velocity to decide dismiss vs
snap-back, and hand that velocity off to the spring so there's no
seam. Use a critically-damped spring for the snap-back and a little
bounce only on the momentum dismiss. Rubber-band at the top edge.

The payoff isn't that Claude knows the word “spring.” It's that the skill carries the exact projection function, the velocity-normalization formula, and the rubber-band equation, so you get a sheet that throws when you flick it instead of one that limply animates to the nearest edge.

The other half of the skill's value is catching what's already broken. Point it at an existing interaction and it audits against the principles — latency on the input path, animations that lock out input, motion that starts from the target value, hard-stops where a boundary should rubber-band.

Review this drawer component against the apple-design skill.
Flag anything that isn't interruptible, any CSS transition on a
gesture-driven property, and any place feedback waits for the
gesture to finish instead of tracking continuously.

It also covers the parts of “Apple feel” that aren't motion: translucent materials with backdrop-filter and content scrolling under them, size-specific letter-spacing (tighten large display text, leave body near zero), and a genuine reduced-motion path that cross-fades instead of just disabling everything.

The whole skill is one bet made concrete: stop scripting motion, start modeling it. Track the finger, carry the velocity, animate from where things actually are, and never lock the user out. Do that and the interface stops feeling like a computer running animations and starts feeling like something you're moving with your hands. That's the entire difference between UI that's fine and UI that's fluid — and now it's a skill you can hand to Claude Code.