From prompt to App Store: the submission process for vibe-coded iOS apps

What "vibe coding" gets you, and what it doesn't

Tools like Claude Code, Cursor, Bolt, Lovable, and v0 are genuinely good at producing working screens, wiring up state, and calling APIs from a plain-English description. That's most of the visible app.

What they don't do automatically: an App Store Connect listing, a privacy manifest, an account deletion flow, App Review-safe permission strings, or a build that's been checked against Apple's guidelines. Those are separate steps a prompt doesn't cover unless you specifically ask for them — and most people don't know to ask.

Step 1: Get from generated code to a signable build

If the app was generated as native Swift/SwiftUI, this is opening it in Xcode, setting a bundle identifier, signing with your Apple Developer account, and confirming it actually runs on a physical device, not just in a preview.

If it was generated as a web app (React, Next.js, etc.) and wrapped for iOS with something like Capacitor, this step also means checking it isn't just a browser tab in an app frame — see the dedicated guide on wrapping a web app for iOS if that's your situation.

Step 2: Fill the gaps AI tools consistently skip

Privacy: add a PrivacyInfo.xcprivacy manifest with correct required-reason API codes, and make sure the App Privacy questionnaire in App Store Connect matches what the app and any third-party SDKs actually collect.

Account deletion: if the app has account creation (many AI-scaffolded apps default to a auth provider like Firebase or Supabase without a delete flow), add an in-app way to delete the account — Apple requires this, and generated auth boilerplate almost never includes it.

Secrets: check that no API key, database URL, or admin credential generated into the client code is exposed in the shipped binary. This is a common side effect of AI tools scaffolding a backend call the fast way.

Permission strings: rewrite any placeholder permission usage descriptions ("This app needs your location") into something specific enough to survive review.

Step 3: Make sure the app clears the functionality bar

Guideline 4.2 is the single most common reason AI-generated apps get rejected: reviewers see a thin, template-feeling app and reject it for minimum functionality, sometimes explicitly citing Guideline 4.2.6 for apps that look like they came from a mass-produced generator.

Before submitting, honestly assess whether the app does something a generic template couldn't — saved state, real personalization, native platform integration. If it doesn't yet, that's worth fixing before review, not after a rejection.

Step 4: Metadata, screenshots, and App Store Connect setup

Write the App Store name, subtitle, and description yourself, or have your AI tool draft them from the real, finished app — not from the original prompt, which usually describes an earlier, thinner version of the idea.

Take screenshots from the actual shipping build. Placeholder or AI-generated mockup screenshots that don't match the real UI are a fast way to get a metadata rejection.

Step 5: Submit, and read the first rejection carefully if it comes

First-time submissions from new developer accounts get closer scrutiny, and a first AI-assisted app is statistically more likely to hit a completeness or functionality flag than a hand-built one — that's not a reason to worry, just a reason to budget a review cycle or two before launch day.

If you do get rejected, resist the urge to just re-prompt the AI tool and resubmit unchanged. Read exactly what guideline was cited and fix that specific thing.