Motion for an app that has to wait.

Café Cal launched to almost no downloads and almost no revenue. So we redesigned onboarding and the paywall. With marketing on top, that took it to about 35,000 downloads.

The rest of this page is the part I led: the motion, and the SwiftUI build it runs in.

None of this was a delight problem, and adding bounce would not have fixed it. People were asking three plain questions and the app answered none of them. Where did my photo go? Is it actually working? Did that count? The motion work was about answering those three questions, on both platforms, without saying anything untrue.

The token file opens with its own grammar: physics-based springs for interactive, easeOut for data fill. Everything below follows from that line and three jobs.

The fix was to stop cutting and fly the photo. The shutter freezes the frame for 50 ms so the moment registers as capture, not failure. The photo then lifts onto an overlay above the tab bar, because SwiftUI's matched geometry cannot cross a tab switch. It flies into the thumbnail on the new processing card while a black backdrop hides the swap and dissolves. The landing is a light tap on the wrist.

The flight uses .smooth and not a spring, and the token comment says why: an overshoot would leave the flying photo a few points off. Bounce is expressive. Here it would just be wrong.

Buell and Norton's labor illusion research is the reason the plan screen does not appear instantly. When a service shows the work it is doing, people prefer it even over an instant result. In one of their studies, 62% of people chose a 30-second wait with visible progress, against 42% when the wait was blind.¹ The same paper sets the limit I design to: effort cannot rescue a bad result.

So the first plan takes five seconds and names four real stages as it goes. Regenerating it takes 1.2. You have already watched the work once, and making you watch it again would be theatre. The meal scan follows the same rule, with a café voice. Frothing up the macros is a joke, but the skeleton it sits on is held for at least 900 ms, so a fast answer never flickers.

The ruler picker sets weight, height, goal and pace, so it is the most-touched control in onboarding. It gets no easing flourish. It follows the finger one to one and snaps to each step. Every value you cross is a medium haptic detent, so you can feel 0.5 kg without looking. The number rolls only the digits that changed. "Use recommended" glides there in a quarter-second and clicks through every value on the way, so the jump still feels like it was made with a hand.

Hitting a goal earns the biggest moment in the app. A disc springs in, a check draws itself, and 90 pieces of confetti fall in that goal's own colour. Our first version used the same trigger for every nutrient, including the ones with a cap, so going over your sugar limit set off a celebration. On August 10 we replaced it with a warning. On September 21 we softened the warning too, because the rejection buzz was, in the commit's words, "literally a rejection buzz for eating a biscuit."

On September 24 we limited each goal to one celebration per day. Anything that happens often has to become quiet, or it stops meaning anything.

Motion is hard to hand off because it lives between a design file and code. My approach is to put the intent into the token file as a sentence. The splash accent's comment reads "an overshoot would read playful, which is the wrong register for a high-contrast serif wordmark." Opus 5.5 can act on a sentence like that. It proposes the curve and writes the SwiftUI. It ports the result to Compose with the conversion written at the top of the Android token file, and records every place the platforms have to differ.

The spring lab below shows the whole idea in one place: one token and three platforms. Choose a token from the app and you get the SwiftUI, the Compose conversion, and a CSS linear() curve sampled from the same physics. Every demo on this page was rebuilt from those numbers.

The part I trust it with most is the audit. For this page, parallel Opus agents read both codebases end to end and gave me back every animation, haptic and Reduce Motion check, with line numbers. They also found what I had missed.

Write the reason next to the number. A spring value without a sentence gets "improved" by the next person, or the next model. A spring value with a sentence gets ported correctly to a platform I did not write it for.

The model is fast. My thumb is the judge. Opus can write, port and audit a spring in seconds. It cannot tell me that a flying photo feels a few points off. I still decide that on a phone, at a quarter speed, with the sound off.