How to submit an app to the App Store and Google Play

Quick answer

Submitting an app to the App Store and Google Play means uploading a signed release build to App Store Connect and Google Play Console, completing each store's listing and privacy forms, and sending the release for review. A finished upload is only the start. Each build must pass Apple's App Review or Google's review, and you then choose when the approved version goes public.

Step 1: Set up developer accounts and app records

"Uploaded to both stores, we're live tomorrow!" lands in #launch. The next morning your marketing lead cannot find the app in either store, because an upload puts a file in a developer console and nothing more. Review, release settings and, for some Google Play accounts, two weeks of closed testing still sit between that file and the public listing.

Start with the accounts. Apple requires a paid Apple Developer Program membership to submit to the App Store, and Google requires a Google Play Developer account. Decide who owns each one. That person needs to accept the agreements and complete the business details, and everyone else should get their own role rather than the owner's password.

Use organization-owned accounts for a company app. If an agency builds it, agree in writing who owns the listings and who maintains the signing setup after handoff.

Pick the identifiers before the first build. iOS uses a bundle identifier and Android uses a package name, such as com.yourcompany.yourapp. The display name can change later without touching the app's identity in the store, because the identifier is that identity.

Create the store records next. Apple's guide to adding a new app in App Store Connect comes before uploading any build, and in Google Play Console you select Create app. Do both early, so account and access problems show up weeks before the launch date instead of the night before.

Keep signing credentials in one shared, access-controlled place, whether that is a CI secret store or a managed credentials service. Write down who can revoke access and how you would recover if that person left.

Step 2: Build a signed release build for each store

A store release is a signed build with a specific identifier, version and build number. A debug build, Expo Go session or web preview cannot stand in for it.

For iOS, you upload an App Store distribution build (an .ipa). A simulator build targets a different environment and cannot be submitted. For Android, new apps on Google Play must be published as an Android App Bundle (.aab), and Play generates optimized APKs for each device from it. Google's app bundle guide explains the difference.

Record the source commit and build number for every build you upload. One app version can have several builds, and the person pressing Submit needs to know which one passed testing.

Run the release build against production settings: backend URL, auth redirect URLs, API keys. A development build can work with configuration the release build never receives.

For an update, install the current store version first, create some realistic data, and upgrade over it. A clean install will not catch a broken migration or a stale saved session.

Step 3: Test the processed build with TestFlight and Play testing tracks

Test the build the store processed, not a local copy. On iOS, TestFlight lets you invite up to 10,000 external testers before the App Store release. On Android, Google Play's internal, closed, open and production tracks let you widen the audience in stages, and an internal testing release reaches up to 100 chosen testers.

Check your Google Play account type before you set a launch date. Personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in continuously for at least 14 days, then apply for production access. Google's testing requirements page says review of that application usually takes seven days or less. Meeting the requirement lets you apply; it does not grant access automatically.

Step 4: Write the store listing and review information

Write the listing from the build you are submitting. Take screenshots from it, describe what it does today, and leave out anything still in the backlog. App Review guideline 2.3.3 asks for screenshots that show the app in use, not only a splash or login screen, and Apple's screenshot upload guide covers sizes and upload.

Set up a support URL that works for strangers. Open it signed out of your company tools, on a phone. A support page behind your SSO is a problem no automated test will catch.

If the app needs an account, create a review account with enough sample data to show the main feature, and test it from a clean install. Avoid a sign-in path that needs someone on your team to approve a code while the reviewer waits.

Put credentials and access steps in the review information fields, never in the public description. List the steps to reach any feature that is not visible right after launch.

Check localized listings as their own surfaces. A price or subscription term baked into a screenshot can be right in one locale and wrong in another.

Give every checklist item a named owner. "Metadata ready" tells nobody whether the privacy answers were reviewed.

Step 5: Complete the privacy and data declarations

Both stores ask what data your app collects and why, and only your code and its dependencies can answer that. A privacy policy generated from a template does not.

Start with an inventory: what leaves the device, which service receives it, and what it is used for. Include analytics, ads and crash-reporting SDKs. Apple's app privacy details and Google's Data safety form describe each disclosure. Their categories and definitions differ, so answer each form on its own terms instead of copying answers across.

Apple's guideline 5.1.1(i) requires a privacy policy link both in App Store Connect and inside the app. Put the same URL in your Play Console listing.

Match every permission request to a feature. Remove permissions that unused dependencies pull in, where your build setup allows it, and write each permission prompt so the user can connect it to the button they just tapped.

Read the rules for your business model. Payments, subscriptions and account systems carry requirements that a free offline utility does not, and storefront rules change, so check the current text for each region you ship to.

Review the code and the forms separately. A form can be complete and accurate on paper while the app still sends data nobody listed, so test the network traffic before you submit.

Step 6: Upload each build and submit it for review

Pick an upload tool. Apple's upload builds page lists Xcode, Transporter, altool, Xcode Cloud and the App Store Connect API. fastlane can script both stores, with upload_to_app_store for iOS and upload_to_play_store for Google Play metadata, screenshots and binaries.

Wait for processing, read any warnings, and confirm the store shows the build number you meant to upload.

On iOS, attach the build to the app version, finish the version's metadata, and submit. Apple's submission instructions separate adding items to a submission from sending it to App Review, so check that the status changed instead of assuming the first button did it. Apple says App Review typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours.

On Google Play, create a release on the track you want, add the bundle, and complete the setup tasks Play Console lists. The release preparation guide walks through it. Google's publishing guide warns that reviews can take up to seven days, or longer in exceptional cases.

Write a short handoff so "submitted" means the same thing to the engineer and the launch owner:

If review reports an issue, read the exact message and reproduce it on the submitted build. Decide whether the fix needs a new build or only new submission information. Resubmitting the same build unchanged in the hope that a different reviewer reads it differently wastes a review cycle.

Step 7: Release the approved version

Approval and public availability are separate settings. Before you submit, App Store Connect asks whether to release the version manually, automatically or in phases, as Apple's publishing overview explains. Apple's guidelines also note that an approved app with a future release date stays hidden until that date, and that an app can take up to 24 hours to appear on every storefront you selected.

On Google Play, check the production release's rollout settings before you send it out, then confirm the listing is live in the countries you chose.

Assign someone to watch crash reports and reviews from the first users, with the authority to halt a rollout or ship a fix.

What to check when a submission stalls

Find out first whether the store received the build. A failed local upload and a processed build blocked by policy need different fixes. Record the first actionable error together with the app identifier, version and destination account.

If the store rejects the upload, compare the build's identifier and signing setup with the store record. A version or build number conflict gets fixed by building again with a higher number; renaming the downloaded file does not change the metadata embedded in the build.

If the build is still processing, check its status in the console before uploading again. Keep the upload receipt or build ID so you can tell a slow upload from a failed one, and avoid leaving several near-identical builds for the release owner to choose between.

If the build processed but the release will not advance, look at the remaining store tasks. Account eligibility, missing declarations and missing review information have nothing to do with compiling the app. Send each blocked task, with the console message attached, to the person who can complete it, and update the handoff record once it moves.

Where Expo fits

EAS Build produces signed release builds for Expo and React Native projects on hosted machines, including the macOS needed for iOS. Once the project and credentials are configured with the first-build guide, the production commands are:

EAS Submit uploads the builds you select to App Store Connect and Google Play, and it runs on macOS, Linux and Windows:

Both commands need EAS CLI signed in to your Expo account and the store prerequisites in place. Pick the exact build you tested. Adding --auto-submit to eas build hands each finished build to EAS Submit automatically.

For iOS, the iOS submission guide covers the upload. The build appears in TestFlight after Apple processes it, usually in 10 to 15 minutes, and you still submit it for App Review in App Store Connect. For Android, the Android submission guide shows that a first eas submit creates the app's first release on the internal testing track, once the app exists in Play Console and EAS has a Google Service Account key. The app stays in draft in Play Console until you finish the store listing and setup tasks.

Limitations

Build and upload services cannot tell you whether your metadata is accurate or whether your app meets store rules, and they cannot shorten review. An upload through any tool, EAS Submit included, is still only an upload.

Next step

Read Apple's App Store Connect workflow and create both store records before you run the first production build.

Verified on 12 September 2026.