Can you put a vibe coded app in the store?

Yes, under the same rules as any other app. Apple's guidelines reject apps too thin to be useful, unique or app-like, and a separate rule says apps made through an app generation service have to be submitted by the owner of the content rather than by the service. So the developer account and the submission are yours. No part of review asks who or what wrote the code.

Do you own the code an AI app builder writes?

With the builders that write a real project, yes, but check how you get it out before you pay. Ownership only counts if there is a download, a Git remote or a command line tool. A product that shows your app only inside its own website is a rental, whatever the marketing says. Ask about the export path first and the feature list second.

What does it cost to publish an app you built from prompts?

Two store fees, plus whatever the builder charges. Apple's program page lists a $99 annual membership. Google Play's signup lists a one time registration fee of US$25. Those two are the only payments that are mandatory to reach a public listing. Everything else, including the builder subscription, is a choice you can change later.

What breaks first in a vibe coded app?

In practice: the data model, permission checks, empty and error states, and anything involving two devices or two people at once. The prompt describes the happy path, so the happy path is what gets written well. Everything around it is inferred, and inference is where a plausible wrong answer hides until a user finds it.

Do I have to be able to read code?

To ship something for yourself, no. To ship something other people depend on, someone does, and it does not have to be you. The cheap version is a few hours of a developer reading the parts that touch sign in, money and other people's records. That review is most of the difference between a real app and a demo that happens to install.

Articles · GuidesUpdated October 2026

Can vibe coding build a real app? Yes, and the last mile is still a person's job.

Yes. A prompt-driven build produces a real React Native and TypeScript project: source files you can open, screens that run on a real phone, and builds that go to TestFlight and to Google Play internal testing. By every test a user applies, that is a real app. It installs, it opens, it does the thing. What it is not yet is a shipped product. The developer account, the review submission, the privacy answers and the decision that the data model is correct are all still yours. If the term itself is new, read what vibe coding is first, then come back for the part about where it stops.

This page takes it in four parts. What actually comes out of the prompt. What the two stores count as a real app. Which of two readers you are, because the honest answer differs for each. Then the human work between a working build and a public listing.

Check which answer applies to you

The short version

The code is real. Whether it becomes a product depends on the reading.

Two claims get mixed together in this question. The first is that AI writes app code that runs. That one is settled: it does, most of the time, for the kind of app most people describe. The second claim is that nobody needs to understand the result. That one is not settled, and it is where vibe coded apps fail in public.

So the useful line is not simple apps against complex apps. It is apps where being wrong is cheap against apps where being wrong costs someone else money, data or trust. The first kind ships from a prompt this afternoon. The second kind ships after a person reads the parts that touch identity, money and other people's records.

What actually comes out of the prompt

Start with the artefact, because arguments about this question usually skip it. A current builder does not hand you a preview trapped inside a website you rent. It writes a project: React Native and TypeScript source, a package manifest, screens, navigation, state, and the native project files the stores need. You can open it in an editor, read it, run it, and change a line by hand. Real apps from prompts are real in a boring sense. The file tree is ordinary.

Newly works this way. You describe the app, it writes the React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, then uploads to TestFlight and publishes to Google Play internal testing. New apps start local-first, with data kept on the phone and no server, until the app needs accounts or shared data. The code leaves as a ZIP from Settings, through two-way GitHub sync, or with the command line tool. That export path matters more than any feature list, because code you cannot take out is a product you are renting.

What does not come out of the prompt is judgement. The generated code still decides how records are shaped, who is allowed to read them, what happens when the network drops, and what happens when two people edit the same row. Every one of those choices arrives looking plausible. Plausible is the failure mode: a wrong answer in the shape of a right one, inside code that compiles and passes the demo.

What the stores count as a real app

There is a second definition of real, and you do not control it. Apple's review guidelines set a minimum functionality bar. An app needs features, content and interface that lift it past a repackaged website, and an app that is not useful, unique or app-like does not belong on the App Store. A thin app fails that bar whoever wrote it. Prompting does not make thinness worse. It does make it much faster to produce.

The same guidelines carry a rule aimed straight at generated apps. Apps created from a commercialized template or an app generation service are rejected unless the provider of the app's content submits them. In plain terms, the account and the submission have to be yours. A builder that presses submit on your behalf is the thing the rule forbids, which is why a sensible one uploads the build and then stops. You press send, and you answer the reviewer.

So the store test is not about authorship. Nothing in either review process asks whether a model typed the code. The rejections that hit these apps are the ordinary ones: too thin to be worth installing, broken on the reviewer's device, or privacy answers that do not match what the app sends. The honest list of what these tools still get wrong is vibe coding limitations, and it is worth reading before you pick the project rather than after.

Apple, App Review Guidelines, section 4.2 Minimum Functionality

Which of two readers you are

The answer splits by who gets hurt when the app is wrong. Reader one is the only person exposed: a tool for their own work, a tracker, a utility, a first version to put in front of ten friendly people. For reader one the answer is yes with no asterisk. A paragraph of description, an afternoon, a build running on their own phone, and the thing exists and gets used.

Reader two is building something other people rely on. Accounts, other people's records, money moving, a date somebody paid for. For reader two the answer is still yes, and then a second job starts. Someone has to read the data model, the permission checks and the error paths. If nobody on that side reads TypeScript and nobody is hired to, the honest answer turns into usually no. Not because the code fails to run, but because nobody will notice the day it runs wrong.

Most projects sit between those two, which is what the checklist below is for. Tick what is true, see how far you sit from reader one, then read ai app development for how the work divides between the model and the person once a first version exists.

Check yourself

Which of the two answers applies to you

Tick everything that is true of the app you have in mind.

Yes, today.

Nothing on this list applies, so you are the only person exposed. Describe it, build it, use it, and fix what annoys you. Weight: 0 of 9.

What a person still has to do before it ships

Between a working build and an app anyone can install sits a list no prompt clears. A paid developer account: Apple's program page lists a $99 annual membership, and Google Play's signup lists a one time registration fee of US$25. Listing text, screenshots, an icon, an age rating. Privacy answers that match what the app actually sends. Identity verification. Then the submission itself, which is a button you press and a form you sign your name to.

On Google Play the gap surprises people building their first app. Personal developer accounts created after 13 November 2023 have to run a closed test with at least 12 testers who stay opted in continuously for 14 days, and only then can you apply for production access. Twelve real people, two weeks, before a public listing exists at all. Internal testing works from day one, which is why a generated app usually lives there first.

Apple moves faster but not automatically. Its TestFlight page says you can designate up to 100 members of your own team as internal testers, while an external group of up to 10,000 needs the first build approved by App Review for TestFlight. So your team can hold the app today and strangers wait for a review either way. None of this is difficult. It is calendar time, and calendar time is the part a demo video never shows.

One item on that list is the one people skip, and it is the one that decides whether the app was ever real. Somebody has to use it in the wrong order, on a bad network, with an empty database, before strangers do it for you. How to do that without a QA team is its own subject: proving it before you ship.

Google Play Console Help, app testing requirements for new personal developer accounts

Which apps come out ready, and what each one still needs

What you are building	Works from the prompt	Needs code a person has read	Store work before launch	Honest answer
A tool only you use	Yes	No	none, it runs on your own phone	Yes, today
An internal app for a team	Yes	the data model	internal testing track only	Yes, this week
A public app with accounts	Yes	Yes	privacy answers, listing, review	Yes, after a reading pass
An app that moves money	the screens	Yes	store billing rules on top	Not from the prompt alone
Health, lending or data about children	the screens	Yes	policy review on both stores	No, not without an owner

Building one you can stand behind

If you want the version that survives contact with users, treat the prompt as most of the typing and none of the responsibility. Ask for the app. Then read four things: how records are shaped, who is allowed to read them, what happens with no network, and what happens on a second device. Those four cover most of what goes wrong after launch.

Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month and there is no free plan. It does not submit the app for review, and there are no built in payments, so the store paperwork and anything involving money stay on your side of the line.

One habit is worth more than the choice of tool. When the agent makes a decision you do not follow, ask it to explain that decision in one paragraph before you accept it. If the explanation does not hold together, you have found the part to read line by line, or the part to hand to somebody who will.

Questions people ask before trusting a generated app

It depends what production means for you. For a single user tool or an internal app, yes, and people ship those weekly. For an app holding other people's records or money, the generated code is a first draft that someone has to read. Models write code that runs. They do not notice when a plausible design is the wrong one, and they cannot be accountable for it.

Describe the app, then read the four things

Write the app down in one paragraph and build the first version. Then read how records are shaped, who is allowed to read them, what happens with no network, and what happens on a second device.

Start building