Shipping a Vibecoded App to the App Store and Google Play

The code is the part the AI helped with. This is the part it can't do for you: getting two of the world's strictest gatekeepers to accept and publish your app. It's not hard, but it's exacting, and almost none of it is code. This guide walks the whole path so submission day is a checklist, not a crisis.

Read the reality check first if you haven't — it sets expectations for the review wall this guide helps you clear.

Before you build: gather the non-code requirements

Both stores require artifacts that have nothing to do with your code. Collect these early — discovering them at submission adds days:

• A privacy policy URL. Both stores require it. A simple page on any domain works. State what data you collect and why.
• App icon in the required sizes (Expo/EAS generates platform sizes from one source image).
• Screenshots for multiple device sizes — at minimum a modern phone; the stores specify exact pixel dimensions.
• A short and full description, and a category.
• A support contact (email or URL).
• Permission justification strings — for every permission (camera, location, etc.), a one-line reason shown to the user. iOS rejects apps whose permission strings are vague.

Step 1: Developer accounts

You need both, and Apple's takes time to approve — start it early:

• Apple Developer Program — $99/year at developer.apple.com. Approval can take a day or two; enrollment sometimes requires identity verification.
• Google Play Console — $25 one-time at play.google.com/console. Approval is usually fast, though new accounts face extra testing requirements (see below).

See what it all costs for the full budget.

Step 2: Set your app identity

Your app needs a unique identifier that never changes once published:

• iOS bundle identifier and Android application ID, both in reverse-domain form: com.yourname.streak.

Set these in app.json (Expo) before your first build. Changing them later means a brand-new app listing, so pick something permanent.

Step 3: Build signed release binaries

Development builds won't do — the stores need signed release builds. With EAS this is one command per platform, and EAS manages the signing credentials for you:

eas build --platform android --profile production
eas build --platform ios --profile production

• Android produces an .aab (Android App Bundle) — the format Google Play requires.
• iOS produces an .ipa, built and signed in the cloud without a Mac.

Let EAS generate and store your credentials (the Android keystore and iOS certificates) the first time. Back up the Android keystore — lose it and you can never update the app under the same listing.

Step 4: Test through the official tracks first

Never ship straight to production. Both stores give you testing tracks, and using them catches problems before real users (and reviewers) see them.

Android — Google Play Console:

• Upload the .aab to Internal testing first — it's near-instant and lets you install on your own devices via a link.
• New personal developer accounts must run a closed test with real testers for a period before production is unlocked. Start this early; it's a hard gate that can delay launch by weeks if you discover it late.

iOS — TestFlight:

• Upload the build (via EAS Submit or Transporter) and it appears in TestFlight after a short processing wait.
• Install TestFlight on your phone and test the exact binary you'll ship.
• Invite external testers if you want feedback before the public release.

Step 5: Fill in the store listings

In App Store Connect (iOS) and the Play Console (Android), create the app listing and complete every section:

• Name, subtitle, description, keywords, category.
• Screenshots and icon.
• Privacy details — both stores make you declare what data you collect and how it's used. Answer honestly; mismatches with your actual behavior are a top rejection reason.
• Content rating questionnaire (Android) / age rating (iOS).
• Pricing (free or paid) and availability regions.

Step 6: Submit for review

Android review is often hours to a couple of days. Promote your tested build from a testing track to the Production track and submit.

iOS review is typically a day or two but less predictable. Submit from App Store Connect. You can request the build auto-release on approval, or hold it for manual release.

Step 7: Handle the (likely) rejection

Plan for at least one rejection, especially from Apple. It's routine, not failure. The most common reasons:

• Vague or missing permission justifications — say specifically why you need each permission.
• "App doesn't do enough" / thin functionality — Apple rejects apps that feel like a wrapped website or a single static screen. Make sure your core loop is clearly functional.
• Privacy policy missing or not matching declared data use.
• Broken flows / crashes the reviewer hit — test the full path on a real device, including sign-in and denied permissions.
• Placeholder content — remove "Lorem ipsum," test data, and dead buttons.
• Using a private or undocumented API — sometimes a package pulls one in; the rejection names it.

When rejected, you get a specific reason. Fix exactly that, reply in the resolution center if you disagree, and resubmit. Don't guess at unrelated changes.

Step 8: After approval

• Android rollouts can be staged — release to a percentage of users first and expand. Use it for your first real release.
• iOS goes live to everyone once you release (or automatically on approval, if you chose that).
• Updates repeat this loop: bump the version and build number in app.json, eas build, test in the track, submit. Increment the build number every submission or the store rejects the upload.

The submission checklist

[ ] Privacy policy URL live
[ ] App icon + screenshots in required sizes
[ ] Permission justification strings written
[ ] Apple ($99/yr) + Google ($25) accounts approved
[ ] Bundle ID / application ID set (permanent)
[ ] eas build --profile production (both platforms)
[ ] Android keystore backed up
[ ] Tested via Internal testing / TestFlight on a real device
[ ] Closed test started (new Android accounts)
[ ] Store listings complete incl. privacy declarations
[ ] Submitted for review
[ ] Ready to fix one rejection and resubmit

The code was the fun part; this is the professional part. Work the checklist top to bottom and the stores go from an intimidating wall to a process you can run again for every update.

Related

• Budget the whole thing: What It Actually Costs to Vibecode a Mobile App
• Set expectations: A Reality Check on Vibecoding Mobile Apps