Originally published on the Motionary blog.
One prompt, one reference video, three models. We asked GPT-5.6 Sol High, Claude Fable 5 and Kimi K3 High to build a Robinhood clone in React Native and Expo, using Reanimated, Gesture Handler and Skia, and match the motion frame for frame. Then we built the same three screens by hand, so there was something honest to compare against.
The question comes up in our DMs constantly, usually phrased as some version of "can I just have the AI do it?" It is a fair question and it deserves a real answer instead of a vibe, so we ran it properly against the three current flagships: GPT-5.6 Sol High in ChatGPT, Claude Fable 5, and Kimi K3 High. Same prompt, same reference video, same starting point, same device, and no rescuing anyone when it went sideways.
The brief: three screens of Robinhood, rebuilt in React Native and Expo. Discover, a token detail screen with a scrubbable Skia chart and a Buy reveal, and the swap keypad where the amount animates digit by digit. Small enough that one prompt is fair, and motion-heavy enough that it cannot be faked with layout. Crucially, the brief was fidelity of motion, not features: match the real app's easing, timing, gesture response, haptics and typography.
This is the video all three were told to match, frame for frame. Everything below is measured against it.
The rules
- One prompt. No follow-ups, no "actually, fix the...", no nudging it back on track.
- Same blank project for all three: a fresh Expo app, TypeScript, nothing pre-installed beyond the template.
- Same reference video attached to the prompt, so nobody was guessing what Robinhood looks like.
- It has to run on a real device. Code that only compiles counts as a miss.
- The clock starts at the prompt and stops the first time the app renders the screen without a red box.
- Tokens and cost are the totals reported for the whole run, thinking included.
- The exact versions, so this stays checkable: GPT-5.6 Sol High, Claude Fable 5 and Kimi K3 High, all run on the same day.
The prompt
Identical for all three, pasted cold, with the video attached:
Recreate the Robinhood app screens shown in the attached video as a React Native
(Expo) app. Build three screens: Discover, Token detail (scrubbable chart with
price + Buy reveal), and the Swap/amount keypad screen.
Priority is fidelity of motion and feel, not features — match the real app's
easing, timing, gesture response, haptics, and typography (numbers should
animate digit-by-digit). Use Reanimated + Gesture Handler, and Skia for the
chart. Mock all data locally; no backend.
Watch the video closely and match what you see frame for frame. Tell me which
interactions you couldn't reproduce and why.
ChatGPT (GPT-5.6 Sol High) — Winner
| Tokens | Cost | Time | Deps added |
|---|---|---|---|
| 2.0M | ~$15 (90/10 in-out) | 32 min to first render | 3 |
GPT-5.6 Sol High got closest. All three screens are there and recognisable as Robinhood: the Discover list, the token detail with a Skia chart you can actually scrub, and the swap keypad. It read a motion brief as a motion brief, which is exactly what was asked, and it did it in half the time and at about 75% of the cost of the runner up.
On frame-by-frame review, the price ticker's digit change is the tell: it rolls per digit, the same odometer motion the reference uses, not a flat cross-fade. The token detail chart and swap keypad both track the reference's layout closely enough that side by side they read as the same screen. What it shares with the other two is the defect below: the ticker and chart redraw through React state instead of a UI-thread worklet, so passages that should feel instant on the finger carry a JS-thread tax the reference never pays.
Hold the applause, though. The winner ships the same defect as the loser, and on an animation brief it is the one defect that cannot be waved through. That part comes after the receipts.
Claude (Fable 5) — Runner up
| Tokens | Cost | Time | Deps added |
|---|---|---|---|
| — (tool doesn't report them) | $19.32 (tool reported) | 1h 3m to first render | 2 |
Claude Fable 5 came second, and it worked the hardest for it. It wrote +2,780 lines and deleted 197 off a single prompt, spent 57 of its 63 minutes actually calling the API, and ran a 99% cache hit rate. The output is the most complete and the most structured of the three. It is also the most expensive at $19.32, and it took roughly twice GPT-5.6 Sol High's time to land in about the same place.
Where the extra effort went is visible, not just implied: the token detail screen is the most fleshed out of the three, with real market-cap and volume stats laid out cleanly. But it drifted from the brief along the way — the reference used Solana throughout, and the detail screen captured here is Bitcoin. Switching that chart to the 5-year range throws a live, on-screen React error, Maximum update depth exceeded, the standard signature of a setState loop inside a useEffect, mid-demo. On the swap keypad, digit entry doesn't roll cleanly either: frames show overlapping, ghosted digits instead of a clean transition, a rougher animation than GPT-5.6 Sol's.
Kimi (K3 High) — Cheapest, and it shows
| Tokens | Cost | Time | Deps added |
|---|---|---|---|
| ~2.6M (estimated) | ~$2 (estimated) | 41 min to first render | 4 |
Kimi K3 High came last, and it is not close. Nothing in its build matched the video. The screens exist and the app boots, after one fix, but almost none of the layout, spacing, typography or motion resembles the reference it was handed. The clearest tell is in the clip above: on the swap screen, whose entire job is a number pad, the digits render scattered out of the grid.
It is comfortably the cheapest, at roughly a tenth of what the other two cost, and this is where cheap stops being a virtue. A build you have to throw away is not a saving, and cost per attempt only matters when the attempt lands.
Two more misses beyond the keypad scatter: the swap screen adds preset quick-amount chips ($10 / $50 / $100) that don't exist anywhere in the reference, and in the captured frames the amount sits at $0 while a finger is already pressing 1 — the tap isn't landing in step with the touch the way it does on the other two builds.
What each run cost
Now the receipts. Tokens burned, dollars spent, and how long each one took to reach a screen that runs.
| Model | Tokens | Cost | Time to run | Ran? |
|---|---|---|---|---|
| Claude Fable 5 | — (not reported) | $19.32 | 1h 3m | Yes |
| ChatGPT (GPT-5.6 Sol High) | 2.0M | ~$15 | 32 min | Yes |
| Kimi K3 High | ~2.6M (estimated) | ~$2 (estimated) | 41 min | After 1 fix |
Totals per run, thinking included. Shorter times and lower cost say nothing at all about whether the result was any good — see the three clips above.
How we costed it: Token pricing is per million and splits by direction, so a single "cost" is always an estimate and it is only fair to show the arithmetic. GPT-5.6 Sol bills $5 per million input and $30 per million output. Our run burned two million tokens. All of it as input would be $10, all of it as output would be $60, and at a realistic 90/10 split it lands at 1.8M × $5 + 0.2M × $30 = about $15, before any tool-call fees. Claude Fable 5 is not estimated at all: the session reports its own total, $19.32, which is the figure in the table. The same panel reports minutes, lines changed and a 99% cache hit rate but no token count, so Claude's token cell is a dash rather than a guess. Kimi K3 High is the weak one: we have no token report for it, so its row is an estimate built from a run of comparable size at Kimi's published per-million rates.
The thing all three got wrong
All three shipped something that worked, and all three shipped something that was laggy. Not subtly. The same failure, three times over, from three different models: far too much React state, changing far too often. Every interaction pushed a fresh setState, every setState re-rendered a tree, and the JavaScript thread never got a quiet frame. The result is dropped frames on the JS side while the app is doing nothing more demanding than moving a card.
Why the JS thread is where this shows up
React Native runs your JavaScript on one thread and composites the UI on another. That split is the whole reason animation on this platform has its own rules. Work that stays on the UI thread keeps painting at 60fps even when JavaScript is busy, and work that needs JavaScript on every frame is at the mercy of whatever else is queued.
A React state update is, by definition, JavaScript work. Drive an animation with one and you have asked the busiest thread in the app to hit a 16ms budget sixty times a second, while it is also reconciling, diffing and running your effects. Turn on the Expo performance monitor while dragging: the UI FPS stays pinned near 60 and the JS FPS falls off a cliff. That gap is the bug, and it is the single most useful thing to look at when a React Native animation feels wrong.
What they wrote, and what it should have been
The shape below is the one that appeared in every run. It is also perfectly idiomatic React, which is exactly why a language model reaches for it.
// What all three reached for: a React render on every gesture frame.
const [offset, setOffset] = useState(0);
const pan = Gesture.Pan().onUpdate((e) => {
setOffset(e.translationY); // JS thread, ~60x a second
});
return <View style={{ transform: [{ translateY: offset }] }} />;
// What actually holds 60fps: the value never enters React at all.
const offset = useSharedValue(0);
const pan = Gesture.Pan().onUpdate((e) => {
'worklet';
offset.value = e.translationY; // UI thread, no re-render
});
const style = useAnimatedStyle(() => ({
transform: [{ translateY: offset.value }],
}));
return <Animated.View style={style} />;
The second version renders once. The value lives in a shared value, the gesture handler is a worklet running on the UI thread, and useAnimatedStyle applies it without React ever hearing about it. Same visible behaviour, none of the cost. The rule is small enough to hold in your head: if a number changes while something is moving, it does not belong in useState.
Worth saying out loud: this is not a dunk on the models. All three wrote more correct React Native in half an hour than most of us wrote in our first month, and the code they produced is code a good React developer would write. That is the actual problem: the idiomatic answer and the fast answer are different answers here, and nothing in the source tells you which one you got. A dropped frame is invisible in a diff. You only find it by holding the phone.
Then we built it ourselves
Same app, built the way we build every drop: by hand, on a real device, tuned until the spring stops arguing with you. No React state anywhere near a gesture, every animated value in a Reanimated shared value, the chart in Skia, the haptics on the frame they belong to.
Motionary — Recommended
| Build time | To install | You get | Deps |
|---|---|---|---|
| 11 hrs (over three days) | 2 min | 50+ drops (one payment, no tokens) | 2 |
On frame-by-frame comparison, this is the only one of the four that matches the reference's price-ticker roll and swap keypad without a visible artifact: no ghosted digits, no on-screen error, no stuck input. The keypad mirrors the reference key for key, including the same 1–9, decimal, 0, backspace order that Kimi's build rearranges and Claude's build cramps. That's the actual difference a Reanimated shared value buys over animation driven through React state: the same interaction, with nothing left to catch on camera.
This clip is the whole pitch of Motionary in forty seconds: animated React Native components you can actually buy, each one built by hand with Reanimated, Gesture Handler and Skia, and shipped as source you own and can read, restyle and rip apart. Think shadcn, for React Native, where the components move.
All four, side by side
The same three measures, with the hand built version in the table. The cost column is deliberately not like for like. A model run is billed per attempt: fifteen to twenty dollars for one screen, again for the next screen, and again every time a run needs a second or third go. The last row is one payment for 50+ animations, already built and already tuned, and it does not start the meter again when you need the next one.
| Model | Tokens | Cost | Time to run | Ships source? |
|---|---|---|---|---|
| Claude Fable 5 | — (not reported) | $19.32 | 1h 3m | Yes |
| ChatGPT (GPT-5.6 Sol High) | 2.0M | ~$15 | 32 min | Yes |
| Kimi K3 High | ~2.6M (estimated) | ~$2 (estimated) | 41 min | Yes |
| Motionary (lifetime pass) | 0 | One payment (50+ drops) | 2 min | Yes |
Cost is a single run for the three models against one payment, forever, for the last row. Time is to a screen that runs on a device.
So which one should you use?
The best AI for React Native UI work, on this evidence, is GPT-5.6 Sol High. It read a motion brief as a motion brief, got closest to the reference, and did it in the least time for the least money. Claude Fable 5 is worth it when you want volume and structure and do not mind paying for an hour of it: second on fidelity, first on thoroughness. Kimi K3 High is hard to recommend for this kind of work at any price, because price is not the problem when almost nothing matches.
The bigger finding is the one none of them escaped. All three are excellent at the first ninety percent, and all three shipped a laggy screen for the same reason: the idiomatic React answer and the 60fps React Native answer are different answers. A model can read every Reanimated doc ever written and still never feel a dropped frame. That last step, holding the phone until the motion stops lying, is the part we sell. It is also the only part the models cannot do yet.
Pay once, not per screen
Every run above bought one screen, for real money, with the animation still to fix. These three Robinhood screens are drops, and there are 50+ more: scrubbable Skia charts, bottom sheets, keypads, carousels, whole screens, each built by hand on a real device until it held 60fps. One payment takes all of them, which works out at about a dollar and a half a drop, and the price does not move when you need the next one.
Get the lifetime pass · Browse the drops
Common questions
Did you use the paid tier of each model?
Yes, nothing here ran on a free tier. GPT-5.6 Sol High ran inside a paid ChatGPT plan, Claude Fable 5 ran through Claude Code, which bills by the token and reported the $19.32 itself, and Kimi K3 High ran at its published per-million rates. The costs in the tables are what the runs burned, not what the subscriptions cost.
Would a better prompt have fixed it?
Partly, and it is only fair to say so. If you already know the failure mode, you can write the fix into the brief: never drive motion from React state, keep gesture values in Reanimated shared values, animate in worklets on the UI thread. A prompt like that would probably have steered all three away from the laggy version. The catch is who gets to write it. You have to know the answer before you ask the question, because nothing in the output warns you the model picked the slow idiom; the code looks identical either way. That is exactly what part two tests: same brief, follow-ups allowed, performance monitor open.
Why was the AI-generated animation laggy?
Because it drove the animation with React state. Every gesture frame called setState, every call re-rendered, and the JavaScript thread ran out of budget, so the JS frame rate collapsed while the UI thread stayed idle. Moving the animated value into a Reanimated shared value and applying it with useAnimatedStyle keeps the work on the UI thread and the stuttering goes away. All three models made this mistake.
Which model do you use day to day?
Claude, mostly, inside Claude Code, because day to day work is editing an existing codebase rather than one-shotting a fresh one, and that is where it is strongest. For a cold start on a brand new UI, this test says GPT-5.6 Sol. What neither of them does is ship a drop: every drop in the catalog still gets written, run and tuned on a physical phone before it goes up for sale.
Can ChatGPT build a React Native app?
Yes, and in this test it was the best of the three at it. GPT-5.6 Sol High turned one prompt into a running three-screen Robinhood clone in Expo in 32 minutes, including a scrubbable Skia chart. What it could not do was make the motion smooth: like Claude and Kimi, it drove animation through React state, so the build stuttered until the gestures were rewritten as Reanimated worklets. AI gets you a screen that works; it does not yet get you a screen that feels right.
Can I buy React Native animation components instead of generating them?
Yes. That is exactly what Motionary is: premium, production-ready animated React Native components, each one built by hand with Reanimated, Gesture Handler and Skia, tuned on a real device, and shipped as source you own. You can buy a drop individually or take the lifetime pass, which is one payment for the whole catalog, these three Robinhood screens included, plus everything that lands after.
This is part one. One prompt, one shot, no follow-ups, which is the harshest version of the test and not how anyone actually works. Part two gives the same three models the same brief with the gloves off: follow-up prompts, the perf monitor open, and as many attempts as it takes to get to 60fps. The interesting question is not who wins cold. It is who can be steered.
If there is a specific app you want the three of them to fight over next, tell us on X and we will put it in the ring. 🐦⬛
Top comments (0)