Skip to main content
Back to module
Mobile App Production · Release

App store submission

Reading1h 19mLesson 1 of 3 in this module

Prepare signing, versions, listings and privacy declarations, and get through store review.

Why it matters

An app is not shipped until people can install it from the App Store or Google Play. Store submission is part engineering, part paperwork: signing, version numbers, screenshots, privacy declarations and policy review. First-time submissions are often rejected for avoidable reasons, which can cost days. Knowing the process lets you plan a release instead of being surprised by it.

Accounts and costs

  • Apple Developer Program: $99 per year (individual or organization). Needed for TestFlight and the App Store. Organizations need a D-U-N-S number.
  • Google Play Console: a one-off $25 registration fee. Google verifies your identity, and new personal accounts must run a closed test with a minimum number of testers for a minimum period before they can publish to production (the current rule has been 12 testers for 14 days; check Play Console Help for today's requirement).

Checked on 2026-10-23. Fees and rules change, so confirm on developer.apple.com and the Play Console Help Center before you pay or plan dates. Fee waivers exist for some non-profits, education and government organizations on Apple's program.

What each store needs

App Store (App Store Connect)Google Play (Play Console)
Build formatSigned .ipaSigned Android App Bundle (.aab)
Testing trackTestFlight (internal and external testers)Internal, closed and open testing tracks
Privacy"App Privacy" details (nutrition label) and a privacy policy URLData safety form and a privacy policy URL
ListingName, subtitle, description, keywords, screenshots per device size, icon, age ratingTitle, short and full description, screenshots, feature graphic, icon, content rating questionnaire
ReviewHuman and automated review against the App Review GuidelinesAutomated and human review against Play policies
Technical rulesBuilt with a recent Xcode / SDKTarget a recent Android API level

Both stores require a way to delete an account from inside the app if the app lets users create one, and a demo account for reviewers if features are behind a login.

Versions and signing

Every upload needs a higher build number than the last:

{
  "expo": {
    "version": "1.2.0",
    "ios": { "buildNumber": "14" },
    "android": { "versionCode": 14 }
  }
}

version is what users see; buildNumber / versionCode must increase on every upload. With EAS you can set "autoIncrement": true in the production profile of eas.json and let the build service manage it.

Signing proves the build came from you. EAS can create and store the iOS certificates and provisioning profiles and the Android upload keystore for you. Back up the Android keystore credentials (eas credentials): Google Play App Signing protects the final app signing key, but losing the upload key still means a support process to reset it.

Worked example: from build to review with EAS

eas build --platform all --profile production      # store-ready .ipa and .aab
eas submit --platform ios                           # uploads to App Store Connect
eas submit --platform android                       # uploads to Play Console

Then:

  1. Test first. On iOS the build appears in TestFlight; add yourself and a few testers. On Android, release to the internal testing track and install from the Play Store link.
  2. Fill in the listing: description, screenshots (real app screens, no misleading images), support URL, privacy policy.
  3. Declare data use honestly: analytics, crash reporting and sign-in all collect data. The App Privacy and Data safety answers must match what your app and its SDKs actually do.
  4. Give reviewers what they need: a demo account, notes explaining any non-obvious features, and contact details.
  5. Submit for review. Choose manual or automatic release after approval, and consider a staged rollout (Play) or phased release (App Store) so a problem only reaches a small share of users first.

Common rejection reasons

  • Crashes or broken features during review (test the exact build you submit).
  • Missing or vague permission usage descriptions.
  • Login required with no demo account provided.
  • Privacy declarations that do not match the app's behaviour or its SDKs.
  • Placeholder content, "beta" labels or links to unfinished features.
  • Payments for digital goods outside the store's in-app purchase system where the rules require it (the rules differ by region and change; read the current guidelines).

Quick recap

  • Accounts: Apple $99/yr, Google $25 one-off (checked on 2026-10-23); confirm on the official sites.
  • Increase the build number every upload; let EAS manage signing and back up credentials.
  • Test through TestFlight and Play testing tracks, fill in privacy declarations honestly, give reviewers a demo account.
  • Roll out in stages so problems reach few users.

Try it

The Do tab is a release checklist you can work through for your own app, with or without paid accounts.

Also in this lesson: