Why did my vibe-coded app get rejected by App Review when it ran fine on my phone? Because the simulator doesn't care how your app handles user data, and the reviewer does. A prompt can produce a build that compiles, launches, and demos well. It can't produce the paperwork Apple now wants about every API that touches a device identifier, a file timestamp, or a user's free disk space.
That paperwork is the privacy manifest. Nobody prompted the LLM for it, so the LLM didn't write it. The submission portal is where that omission turns into a rejection letter.
The Build Runs. The Submission Still Fails
Founders keep showing up at App Store Connect with a weekend build and the belief that the hard part is behind them. Geek Vibes Nation's coverage of what happens when vibe-coded apps hit App Review lays out the pattern plainly: the prototype looks magical in a demo, and then it meets a reviewer whose checklist the prompt was never shown.
The checklist is where the privacy manifest lives. Starting May 1, 2024, any new app or app update uploaded to App Store Connect has to declare its use of required-reason APIs inside a PrivacyInfo.xcprivacy file, or the submission gets kicked back. A vibe-coded build almost never ships with one, because the model wasn't told to produce one and the human prompting didn't know to ask.
The Manifest Is the Thread Everything Else Hangs On
Pull on the manifest and the rest of the problem unspools. The file itself is tiny, but what it forces you to know about your own app is enormous.
To fill it out honestly, somebody has to be able to answer, API by API and SDK by SDK, what data the app touches, why it touches it, where it sends it, and whether any of that qualifies as tracking. Apple's own WWDC session on privacy manifests walks through exactly that: declare the data types collected, the reason for each, and whether the data is used for tracking under App Tracking Transparency. A prompt that said "build me a habit tracker" produced none of those answers.
The Same Manifest Exposes the Data-Handling Problems Underneath
The declaration doubles as a mirror held up to code the author never read. When engineers sit down to complete it on a vibe-coded project, they tend to surface the same handful of issues in roughly the same order: undeclared required-reason API calls buried in generated helpers, third-party SDKs whose own manifests the project never pulled in, data flows the author can't explain because they never wrote the networking layer, and tracking behavior that trips App Tracking Transparency rules the submission does not acknowledge.
Source Review Alone Won't Catch It
You can read every line the model produced and still miss the rejection reason. The manifest problem lives one layer down, in the compiled binary, in third-party SDK behavior, and in runtime calls that only appear when the app is being used.
That's why experienced engineers tend to run a vibe-coded submission through binary analysis, network inspection, and a full pass over every dependency's own privacy posture before anyone touches the Submit button. Unglamorous work. It's also the work that turns a prototype into something a reviewer will accept and a user can trust with their data.
Where the Engineer Steps Back In
The handoff from prompt to launch comes down to a set of specific tasks the model can't do for you. On a vibe-coded iOS submission, the short list usually looks like this:
- Audit required-reason API calls. Walk the generated code and every dependency to find each API that needs a declared reason, and record the reason that actually applies.
- Reconcile third-party SDK manifests. Pull in each SDK's own privacy manifest and signature, and resolve any conflict with what the app itself claims.
- Map real data flows. Trace what the app collects at runtime, where it sends it, and whether any of it crosses the line into tracking under ATT.
- Sign off on the submission. Take human accountability for the PrivacyInfo.xcprivacy file and the App Store Connect answers that go with it.
A model can draft any of these. It can't be accountable for them. The accountability for what the app collects, where it sends it, and what happens if it leaks still sits with a human who understands the code well enough to sign their name under the manifest. That's the part of shipping an app no prompt has shortened yet.