What can you build with vibe coding? More than the sceptics say, and less than the demos imply.
The honest answer is not a list of impressive things somebody built once. It is a line. On one side are apps that come out working on the first or second attempt. On the other are apps that come out looking finished and failing in ways a beginner cannot see.
The line is not about ambition or subject matter. It is about whether the thing can be checked. Anything you can look at on a screen and judge immediately tends to come out well. Anything whose correctness only shows up under real conditions tends not to.
See what comes out workingThe short version
The dividing line is not difficulty. It is whether you can tell that it worked.
A screen is easy to check. You look at it. A payment flow under a flaky network, a background sync, a permissions edge case on one Android version: none of those announce themselves, and that is what makes them expensive rather than hard.
So read the map below as a checkability map. The further down it you go, the more the work shifts from describing what you want to verifying what you got, and verification is the part no tool does for you.
What comes out working most of the time?
Screens and navigation. Forms and validation. Lists that filter and sort. Local storage for the user's own data. Calls to an API that already exists and returns JSON. Light theming and layout. This is the large majority of what a small app is made of, and it is the part where describing the intent genuinely is faster than writing it.
Anything that is essentially a structured view over data falls here too: trackers, checklists, calculators, catalogues, booking forms, internal tools. The logic is visible on the screen, so when it is wrong you can see that it is wrong, which is the property that makes iteration fast.
These are also the apps that clear Apple's minimum functionality bar without effort. Guideline 4.2 asks for features, content and UI beyond a repackaged website, and a working tool that does one thing is comfortably past that.
The pattern underneath all of these is that the state is small and local and the rules are the ones you stated. Where generated code is weakest is where the rules are implied rather than written: what happens on a retry, what the app should do when two things arrive out of order. On a screen full of forms, almost nothing is implied, which is why the hit rate is high. For the background on how this way of building arrived, what vibe coding is sets it out.
Apple, App Review Guidelines, 4.2 Minimum Functionality, read 7 October 2026
Where does it hit a wall?
Device hardware is the first wall, and it is a practical one rather than a conceptual one. Camera, Bluetooth, NFC and the motion sensors cannot be judged in a simulator, so the loop that makes vibe coding fast, change and look, stops working. Expo's own camera documentation points you at a development build on a real device for exactly this reason.
Real time and multi user features are the second. Anything where two people see the same thing at the same moment brings a server, a connection that drops, and conflict rules. The code for it can be generated. Whether it is correct is not something you can see on a screen.
The third is anything regulated or financial. Not because it cannot be written, but because being wrong has a cost that does not show up in testing, and the right standard there is a person who knows the domain reading the code, which is a different exercise entirely.
The honest framing for all three of these walls is that they are verification problems rather than generation problems. The code can be produced. Knowing it is right needs a device, a second user, or a domain expert, and none of those are things a prompt supplies. Vibe coding against no code is a useful comparison here, because no code platforms hit the same walls from a different direction.
Do the stores care that you vibe coded it?
Nothing in Apple's App Review Guidelines asks how an app was written. The clause people quote is 4.2.6, and it is about who presses submit: apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content, and such services should not submit on behalf of their clients.
So the constraint is procedural, not technical. You publish under your own developer account, as the owner of what the app contains. That is worth planning for because it is the step people assume is handled for them.
Guideline 4.2.2 is the one that bites what gets built rather than how. Other than catalogs, apps should not primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links. Plenty of quick vibe coded ideas are exactly a collection of links.
It is also worth separating what the stores forbid from what they merely make harder. Nothing stops you shipping an app with a camera or a login. The rules that actually reject apps are about shape and about who submits, and both are knowable in advance. If you are choosing a tool partly on this basis, the comparison of AI coding tools covers which ones leave you able to fix a rejection yourself.
Apple, App Review Guidelines, 4.2.2 and 4.2.6, read 7 October 2026
So what is actually worth building this way?
Internal tools, first versions, and anything where the alternative is a spreadsheet. These are the cases where the value is in existing at all, where the person specifying it is the person using it, and where being able to change it next week matters more than being perfect this week.
They are also the cases where the usual objection does not apply. Nobody needs a second opinion on the architecture of a tool that four people in one office use to log deliveries. They need it to work by Thursday.
What to avoid for a first attempt is the app whose whole point is one of the hard categories. A messaging app is a real time problem wearing a UI. A fitness tracker is a sensor problem. Build the thing whose difficulty is in the screens, and add the hard part once the rest is standing.
The last filter is whether the app is worth the effort at all once it is this small, and that is a question about the idea rather than the method. App ideas that make money is a reasonable sanity check, because the ideas there are sorted by what they demand of you rather than by how they sound.
A capability map, by how easily you can tell it is right
| Category | Example | How it usually comes out | What decides it |
|---|---|---|---|
| Screens and forms | A booking form, a checklist | Works, first or second attempt | You can see it is right |
| Local data | A tracker that stores on device | Works | Visible on screen |
| Existing API | Pulling a public JSON feed | Works, with fiddling on errors | Failure is visible |
| Device hardware | Camera, NFC, Bluetooth | Plausible, needs a real device to judge | Simulator cannot test it |
| Real time and multi user | Chat, live leaderboard | Looks finished, breaks under conditions | Correctness is invisible |
Building on the easy side of the line
The practical approach is to keep the first version entirely in the top half of that table, then add the hard parts once the app exists and you have somewhere to add them to. With Newly you describe the app in plain English and get a real React Native and Expo project you own.
That the output is an ordinary codebase is what makes the second half possible later. Adding a camera or a backend to a normal Expo project is a known task with documentation behind it. Adding it to a closed platform is a migration.
Newly is a paid product from $25 a month, with no free tier.
Questions people ask about what vibe coding can build
Yes, and internal business tools are among the best fits, because the person describing the app is usually the person who will use it and can tell immediately whether it is right. The cases that go badly are the ones where correctness is invisible until something has already gone wrong.
Start on the side of the line you can check
Describe the screens and the data, get a real Expo project you own, and add the hard parts once the thing exists.
Start building