A few weeks ago I read an AI’s answer to a simple question: what are the biggest flaws of vibe-coding tools for building mobile apps?
It was a sharp list. Web wrappers passing as native. The deployment wall. Invisible technical debt. Device fragmentation. All real, all fair.
What stayed with me wasn’t any single flaw. It was that the whole conversation (the tools, the threads, the takes) is about generating the app. Almost no one talks about what happens after.
And the “after” is where a mobile app actually lives.
Generating an app is the demo. Shipping it, getting it past Apple, and keeping it alive for three years: that’s the product.
It starts with “native.”
A lot of tools generate embedded web or React Native and dress it up as an app. It holds up in a demo. Your users feel the difference a few days later: the scroll that stutters, the transition that “feels like the web.”
The telling part is that the newer tools are admitting it. In February, Rork dropped React Native to generate real Swift, on the logic that people who want an iOS app want an actual iOS app. They’re right. It’s a bet some of us made a long time ago, and it’s good to see it valued.
Then comes the wall almost no one mentions: publishing.
Generating the code is one thing. Getting it into the App Store is another, and it stops most non-developers cold: certificates, provisioning profiles, Apple review.
Here’s a number from our side, because I think it’s the one missing from most of these threads. Apple rejects roughly 42% of apps on their first submission, and that’s for apps prepared by people who do this for a living. Now picture it with generated code you don’t control and a rejection notice you can’t read.
The skill isn’t avoiding rejection. It’s recovering from it. For us, about 91% of those first rejections end up accepted once the team steps in.
And then the app has to keep living.
Updates when the OS shifts. Data migrations. Notifications. Users. Generation tools mostly stop at version one, which means reopening the code and re-generating it at every change, breaking three things to fix one.
I’ll be fair about what vibe coding does well, because it does: when you can describe a need precisely, it translates it faithfully, including custom logic no template covers. That’s genuinely useful, and we’ve built a version of it into our own product.
But the demo is the easy 20%. The 80% after it is unglamorous infrastructure: native fidelity, store review, the long lifecycle. It doesn’t make a good thread. It’s just the difference between an idea and an app that’s still standing next year.
Which brings me back to the AI’s list. It named some good tools. It also left out the company I help run, which has been compiling native apps and getting them through the stores since 2011.
Honestly, that’s fair. We don’t make much noise. Consider this me making a little.
The real question was never “can an AI generate an app?” It can, and that’s a good thing. The question is who handles the road after the demo.
If you want the long version, the three walls with the numbers, I wrote it up here.
And if you’ve shipped something vibe-coded and hit one of these walls, I’d genuinely like to know which one in the comments.