Hey {{ subscriber.first_name | strip | default: "there" }},

I’ve been arguing with myself about which model to use for mobile dev, so I did the boring thing and actually measured it.

Three flagship models. One prompt. No revisions.

• Fable 5
• GPT-5.6 Sol
• Kimi K3

The task: build a complete calorie tracking app in Expo. Onboarding, auth, a paywall, camera-based meal scanning with AI calorie estimation, charts, history, notifications, Apple Health sync, Live Activities, and home screen widgets.

​→ Watch now the Raw Results​

The setup

Each model got an identical starting point: a fresh npx create-expo-app, a .env with API keys, and a couple of agent skills installed. Nothing else.

The third-party stack was fixed for all three:

• ​Clerk for auth and user management
• RevenueCat for subscriptions
• Gemini for image analysis

I picked Clerk here on purpose. Auth is the one part of an app where “almost right” means “your users’ accounts are exposed.” There are a lot of edge cases and a lot of ways to quietly get it wrong. Clerk ships a CLI and agent skills, so the models had a real path to a correct integration instead of hand-rolling sessions and hoping.

Then I hit enter and walked away.

How long it took

Here is how much each model took to complete the whole app:

• 5.6 Sol: 48 min
• Fable 5: 1h 26m
• Kimi K3: 1h 54m

Kimi was slowest, and not because it was being careful. It made more mistakes and had to rebuild parts of the app several times.

And this is how much each model spent:

• 5.6 Sol: $23.99
• Fable 5: $82.30
• Kimi K3: $17.20

Yeah. Fable cost roughly 4x what the other two did.

Which sets up the actual question: is a 4x more expensive run 4x better?

Three things I did not expect

1. All three shipped working native features. Apple Health permissions, Live Activities, home screen widgets. All implemented, and mostly working, from a single prompt. Two years ago I’d have spent a weekend on the widget alone.
2. Only one model added Terms of Service and Privacy Policy links to the paywall. The other two would get rejected by App Review. It wasn’t the expensive one.
3. Two of the three reinvented the modal header instead of using the one the OS gives you. Same mistake, same weird spacing, same broken scroll. Models share bad habits the way developers do.

There’s a lot more in the video: which one nailed the bottom tabs, whose keyboard handling falls apart the second you open the numeric input, which widget throws an error at the large size, and the one model that built its charts with a library while the others hand-rolled SVG.

The scores

I scored all three on functionality, design, and native features, then put the totals side by side.

One model scored more than the other two combined. The other two tied.

I’m not going to spoil the number here. Watch the breakdown:

​→ Watch: I gave 3 AI models one prompt to build the same app​

​

It’s a full side-by-side. Three simulators running at once, screen by screen, from onboarding to paywall to widgets.

Let me know which one you’d have bet on. Reply and tell me. I want to see how wrong the internet is about this.

See you in the next one, Vadim

P.S. Every app in this test is genuinely close to shippable. Not “impressive demo” close. “Polish it for a weekend and put it on the App Store” close. That’s the part I’m still processing.

Thanks to Clerk for sponsoring this video and for being a long-term partner of the channel. If you’re building auth into a React Native app, their CLI and agent skills will save you the week you were about to lose to session edge cases. Set up a free project → ​