A rejected submission costs you a launch window. A shipped build that leaks user data costs you the account, the reviews, and sometimes a lawsuit. That's the real price tag sitting under the current enthusiasm for prompting an LLM into a working iOS app over a weekend, and it explains why so many of these submissions keep bouncing back with reviewer notes that read less like a form letter and more like a senior engineer's code review.

The prototype looked magical in the demo. The reviewer sees a build that compiles, runs, and silently fails every checklist Apple enforces. Geek Vibes Nation has a useful piece on why prompted prototypes still need engineers, and the pattern it describes is worth walking through here, phase by phase, from the first prompt to the moment the rejection email lands.

The Prompt Produces Something That Runs, Not Something That Ships

The first stage feels like the finish line. A founder describes an app in plain language, an LLM returns a project that opens on the simulator, and the screens look like the sketch. What you have is a working build dressed up as a working product.

Everything a reviewer looks at after the splash screen is missing. There's usually no demo account, no handling for empty states, no retry logic when the network drops, no settings for the permissions the app silently asks for. The happy path works. Any other path shows a blank screen, a spinner that never resolves, or a crash.

This is also where security and data-handling defaults get set, usually without anyone noticing. Generated code tends to hardcode API keys in the client, store tokens in UserDefaults, pass user input straight into prompts for a backend model, and ship whatever third-party SDKs the training data remembered. None of that shows up in the demo. All of it shows up later.

The Submission Hits a Checklist the Prompt Never Saw

Apple's reviewers work from a published rulebook, and it's long. The App Review Guidelines are organized into Safety, Performance, Business, Design, and Legal, and the "Before You Submit" checklist at the top is the one most prompted builds fail on contact: test for crashes and bugs, make sure metadata matches the app, provide a working demo account, and keep backend services live during review.

A handful of guideline numbers come up again and again on vibe-coded submissions. The usual suspects:

• Guideline 2.1, App Completeness. Placeholder copy, broken links, a demo login that doesn't work, a backend that was spun down between the build and the review. The LLM wrote the screen that reads the data; nobody made sure the data was there when a reviewer tapped the button.
• Guideline 4.2, Minimum Functionality. Thin wrappers around a website, a single-screen utility, or an app that is visibly a template with the colors swapped. Prompted builds land here constantly because the model is good at producing a shell and bad at producing a reason the shell deserves to be an app.
• Guideline 4.3, Spam. Duplicate submissions and me-too entries in saturated categories. Apple reviewed roughly 9.1 million submissions in 2025 and rejected about 2.09 million of them, and a meaningful share of those were variations on apps that already exist.
• Guideline 5.1.1, Data Collection. Missing privacy policy, a privacy nutrition label that doesn't match what the app actually does, permissions requested without a usage string that explains why. Generated code is especially bad at keeping the manifest, the label, and the policy in sync, because three different files have to tell the same story and the prompt only wrote one of them.
• Guideline 2.3, Accurate Metadata. Screenshots that show features the app doesn't have, a description written for a different build, keywords stuffed in the name. Reviewers compare what's on the store page to what's in the binary, and the two drift fast when a model is iterating faster than the listing is.

Experienced Engineers Have to Step Back In

Fixing a rejection is rarely a one-line patch. By the time the email arrives, the issues the reviewer flagged are usually symptoms of choices made at the prompt stage, and unwinding them means someone has to read the code the model wrote and decide what to keep.

That's the work experienced engineers do before resubmission, and it tends to look the same across projects: move secrets out of the client and into a server the app calls, replace ad-hoc storage with the Keychain for anything sensitive, add real error states and retries around every network call, write the usage strings and the privacy label so they match what the code actually does, and build the demo account and seed data the reviewer will use. None of it is glamorous. All of it is what separates a build that runs from a build that ships.

The uncomfortable part is that the same pattern shows up on the second submission if nobody changes how the code is being produced. Prompted output is a useful first draft, not a release candidate, and shipping it as one is how a launch window turns into a lost quarter.