The Vibecoding Apps Nobody Uses: An Honest Look

Every claim here is either something the tool documents about itself or something reviewers report, and the two are labelled separately throughout.

There are two kinds of claim in what follows and I am going to label every one of them.

Documented fact means it comes from vendor documentation, Apple's own guidelines, a platform's own support pages, or reporting with a named source. Things like "Lovable does not support React Native" or "Bolt's project slug is immutable after the first build" are in that category.

Aggregate user sentiment means it comes from public reviews. Reviews are real — people wrote them, and the pattern in them is information. But a review is a report of one person's experience, filtered through frustration, and a rating average is not an audited finding. When I quote review data I will say the sample size, name the platform, and describe the claims as what reviewers report rather than as what happened.

Mixing those two together is how this genre gets people sued, and more importantly it is how you end up believing something wrong. If you only read one section of this post, make it that distinction.

Where a claim comes from reporting rather than documentation, it is attributed as such: TechCrunch's reporting on the category's traction is the main secondary source here, and store-volume context comes from 9to5Mac's coverage of the submission surge.

Each builder has a real strength, and starting from the strength rather than the complaint gives a more useful picture of where it fits.

Each of these does something genuinely well. I am going to say what that is before I say anything else, because the category is usually written up as either a miracle or a scam and it is neither.

Rork produces the most polished native-feeling UI of the group. It targets React Native and Expo, with native Swift output on its top tier, and ships plugins for the things that usually take a beginner a week — Sign in with Apple, push notifications, App Store deployment. Pricing runs from a free tier through roughly $20–25 for about 100 messages up to a Max tier around $200, which works out to about $0.20 a message. If your goal is a screen that looks like someone designed it, Rork gets there faster than anything else here.

a0.dev (Y Combinator W25) is the fastest path from idea to published app. React Native and Expo, real .tsx files, one-click connection to App Store Connect and Play Console, and a tester app that lets people try your build without Xcode. Free for one project, $20 a month for Pro at 100 messages a day, scaling up to around $800 a month. Pro includes source export, which as you will see below is the single most consequential feature in this whole category. Its documented limits: mobile only, thin backend support beyond Convex and Supabase, and context loss on larger projects.

Vibecode raised a $9.4M seed from Seven Seven Six and builds for iOS, Android and web on React Native and Expo. It has full Expo source export, a Cloud tier that provisions database, auth and storage from one prompt, and a guided submission wizard. It is also very new, its Android native builds are listed as coming soon, and it was blocked by Apple in March 2026 — more on that below.

Replit brought its agent to mobile with React Native, Expo Router, Replit Postgres, EAS and Stripe wired together, marketed as "text to App Store" with one-button submission and an Expo Go QR preview. For someone already living in Replit it is the least friction available. It was also blocked by Apple in March 2026.

Anything produces native output on Expo and Postgres, exports to GitHub, and manages builds for you, at roughly $240–600 a year. It was removed from the App Store on 26 March 2026, reinstated on 3 April, then removed again.

Bolt.new is a web tool that does build Expo apps, which surprises people. RevenueCat is integrated for in-app purchases. The catch is documented in Bolt's own support docs: projects created for web do not easily switch to mobile, so you have to say "mobile app" in the first prompt or start over. The project slug is immutable after the first build. And you still need Node, Git, the EAS CLI and paid store accounts — Bolt does not remove the parts of shipping that actually take time.

Lovable cannot build native mobile apps at all. This is documented, not an opinion: there is no React Native or Expo support, and the feature request for it is open. Lovable is a web tool that is very good at web. What people do instead is wrap the web output in Capacitor or a WebView and submit that, which walks straight into Apple guideline 4.2, minimum functionality. That is the guideline for apps that are a website in a shell. This is the most common expensive mistake I see: someone builds something genuinely nice in Lovable, wraps it, submits it, and gets a rejection they did not know was structural. There is more on this in why your AI-built app got rejected.

Where a builder documents its own integration path, that documentation is the fairest description of what it intends to do — Bolt's Expo integration docs are a reasonable example, and Expo's own agent guidance shows what the same job looks like outside a closed builder.

They all hit the same wall in the same place: the moment the app needs something the builder does not generate.

Here is the finding that recurs across hands-on reviews of these tools, quoted as one reviewer put it after working through Rork:

That is the shape of the problem in one sentence. The first screen is excellent. Create, read, update, delete is fine. Then you ask for something with actual logic in it — a streak that has to survive a timezone change, a state machine that has to handle a cancelled subscription, an offline queue that reconciles when you come back — and the output stops being something you can accept without reading.

This is not a criticism unique to prompt builders. It is the same wall that shows up in the development build cliff and in every honest account of agent-assisted coding. The difference is what happens at the wall. With a source-first workflow, you open the file and fix it. With a prompt-only builder, you prompt again, and hope, and burn credits.

The wall is not a quality ceiling, it is a scope boundary. These tools generate application code confidently and stop at everything around it: native modules, build configuration, store metadata, privacy declarations, entitlement validation. None of that is exotic — it is simply not what the generator was built to produce, so the first time you need any of it, you are outside the tool rather than inside it with a harder problem.

Billing is the most consistent complaint in this category, and it is worth reading as a pattern rather than as one company’s problem.

This section is aggregate user sentiment, not documented fact, and I want to be unambiguous about that.

On Trustpilot, Rork carries a rating of 1.8 out of 5, with 83% of reviews at one star. The sample size is 23 reviews. Twenty-three. That is small enough that a handful of unusually motivated people move the average several points, and unhappy customers write reviews far more readily than happy ones. Treat the number as a signal that something is generating friction, not as a measurement of how the product performs.

The patterns reviewers report cluster into three:

• Billing shock — charges larger or more frequent than expected
• Credits forfeited on cancellation — unused credits disappearing when a subscription ends
• Projects locked after cancellation — losing access to work after stopping payment

I have not independently verified any of these, and I am not asserting Rork's billing works this way. What I can say is that all three complaints are about the same underlying thing: the product holds your work and your prepaid value, and the terms of that arrangement were not clear enough to the people writing these reviews.

That underlying thing is worth your attention regardless of whether the specific complaints hold up, because it is structural to the whole category, not to one vendor. If your project lives inside a platform, and your unused capacity lives inside a platform, then your relationship with that platform is not "a tool I use". It is a dependency with your work inside it. Read the terms before you buy credits, and check what happens to both the credits and the project if you stop paying. That advice is free and it applies to every product on this list.

Building inside a closed builder means your product depends on a company whose roadmap and pricing you do not control.

Three of the tools above — Vibecode, Replit and Anything — were blocked or removed by Apple during 2026. That is documented.

Apple's stated basis was guideline 2.5.2, which prohibits downloading, installing or executing code that introduces or changes functionality. The specific objections reported were that generated apps rendered inside embedded web views rather than opening in an external browser, and that Vibecode generated software specifically for Apple devices. Anything's timeline was the messiest: removed on 26 March, reinstated on 3 April, then removed again — reportedly because it could not market itself as an app maker. Its co-founder, Dhruv Amin, described it publicly as "a long saga", noting that after December they and everyone else in the category started getting updates blocked, and that the company went through four technical rewrites.

Two things need saying about this, and both cut against the easy narrative.

Apple explicitly told MacRumors there is no rule targeting vibe coding. This is existing-guideline enforcement, not a policy aimed at the category. Both Replit and Vibecode were reportedly close to approval after agreeing to open generated content externally.

And 2.5.2 is enforced at Apple's discretion. Commenters on Hacker News made the obvious point that Swift Playgrounds and Pythonista both run user-supplied code and have survived for years. That inconsistency is real, and it is exactly why this is a risk rather than a rule: you cannot predict it, and you cannot appeal it into predictability.

Now apply that to your own position. If your app exists as a project inside one of these platforms, and the platform gets removed from the App Store, your codebase is inside a company that is now in a fight with its distribution channel. You are not a party to that fight and you cannot influence it. That is a real risk with a real probability, and almost nobody prices it in when they pick a builder.

This is the same risk any team takes on a closed platform, and it is worth pricing the same way: what does it cost to leave, and how long would leaving take? Deciding when to shut an app down is the adjacent question, because a product you cannot migrate and cannot afford to run has already made the decision for you.

Source export is the feature that decides the ending, because it converts platform risk into an ordinary migration.

Everything above converges on one criterion.

Can you get your code out, as real files, and keep working on it without this vendor?

If yes, then the worst case is that you lost some money and some time, and you continue in a normal repository with a normal toolchain. The builder becomes what it should have been all along: a fast way to get past the empty project, not a place you live.

If no, then every other consideration is downstream of a single point of failure. Pricing changes, credit policy, App Store removal, the company shutting down — each of those is now an existential event for your project rather than an annoyance.

On that criterion the group splits cleanly. Vibecode offers full Expo source export. a0.dev offers source export on Pro. Anything exports to GitHub. Bolt produces a real Expo project you can take. That is the half of this list where the downside is bounded.

So the practical rule is: export on day one, before you have anything worth losing. Not when you hit a wall, not when a pricing email arrives. Day one, while the project is small enough that verifying the export actually builds takes ten minutes. An export you have never tested is not an export.

The test is simple: can you clone the repository, install dependencies and build it without the platform? If the answer is no, every limitation you accept today is permanent. If the answer is yes, the builder is a starting point rather than a destination, and the review guidelines become your constraint instead of the vendor's roadmap.

The people who ship tend to end up in the same place, and it is usually not where they started.

The pattern is consistent enough to be boring: Expo plus Claude Code, in a normal repository.

What made that viable is not a change in the models. It is that Expo now ships first-party agent support. The Expo plugin is installable with claude plugin install expo@claude-plugins-official, and it is the only mobile plugin in Anthropic's official marketplace. create-expo-app scaffolds a CLAUDE.md that contains just @AGENTS.md, plus a .claude/settings.json with the plugin enabled — so a new project is agent-ready before you have written a line. Expo's own guidance is to put project instructions in AGENTS.md rather than CLAUDE.md, so they live in one place. On top of that, expo/skills provides roughly 25 skills covering routing, native UI, animation, design systems, upgrades and EAS.

That is the difference. A prompt builder gives you an agent with a vendor's opinions baked in and a wall you cannot see past. A framework with first-party agent support gives you the same generation quality with the files in front of you, your own git history, and the ability to read what was written. The setup takes about fifteen minutes, is covered step by step in the Expo and Claude Code setup, and sits inside the full path laid out in how to ship a mobile app with Claude Code.

It is not magic. You still hit development builds, signing, store review and everything in the growth stack an agent can drive afterwards. But nothing between you and the code is owned by someone else. Most of them end up on the path described in the Claude Code mobile pillar.

There are real cases where a prompt builder is the correct choice, and they share a shape: short-lived, low-stakes, or purely for validation.

I want to be fair here, because there are three situations where I would actively recommend one.

Validation. You have an idea and you want to know whether anyone wants it. Building a real thing to answer that question is expensive. Generating something in an afternoon, putting it in front of ten people and watching them use it is a good trade, and the code quality is irrelevant because the code is not the artifact — the answer is.

A deliberate throwaway. Internal tools, a demo for a pitch, a one-week prototype with a known end date. If nothing is going to be maintained, maintainability costs you nothing.

A non-technical founder before funding. If you cannot write code and you have no budget for someone who can, the choice is not "prompt builder versus proper stack". It is "prompt builder versus nothing". Something you can show is worth more than a specification, and it will be rebuilt anyway once there is money.

Notice what all three have in common: the output is not intended to become the product. That is the line. Cross it — decide the generated thing is the product and you will maintain it — and every constraint in this post becomes yours. If validation is the goal, validating the idea first is cheaper than building anything, and MVP scope decides what the build has to include.

One number frames the whole category, and it is about usage rather than downloads.

Fastly surveyed roughly 800 developers and found that about 95% reported having to spend extra time fixing AI-generated code. That figure comes via TechCrunch's reporting rather than a primary release, so treat it as directional rather than precise.

Even so, it says the thing that matters. The population reporting this is not people who tried AI once and gave up. It is people who use these tools and kept using them, which is why the number is 95% and not 50%. Fixing the output is not the exception. It is the normal condition of the work.

Which means the question to ask about any tool in this category is not "does it produce working code" — none of them reliably do, and neither does any other AI coding tool. The question is how expensive is it to fix the output. That cost is almost entirely determined by whether you can see and edit the files.

Use them for the afternoon they are good at, and plan the exit before you need it.

If you want to test an idea this weekend, use one. a0.dev if speed matters most, Rork if the demo has to look good, Vibecode if you want the backend provisioned for you. Export the source before you build anything you would be upset to lose, and verify the export compiles.

If you intend to ship and maintain a real app, start with create-expo-app and Claude Code. It is slower on day one and faster from week two, and the reason is not code quality — it is that when you hit the wall, and you will, you can open the file.

And if you are using Lovable and planning a mobile version: it cannot build one. Wrapping the web app is a 4.2 rejection waiting to happen. That is not a criticism of Lovable, which is good at what it does. It is just a boundary worth knowing before you pay for a developer account.

The category is not a scam. It is a set of genuinely impressive tools with one structural weakness — they hold your project — and one clean mitigation, which is to take your code and go. The people quietly shipping have all worked that out. It just does not make an interesting launch post.

If you decide to move, the full shipping path is the destination most teams land on, and the first 1,000 users plan is the part no builder was ever going to do for you.