How to Publish an Expo App to App Store and Google Play

You built your app in Expo, but getting it into the App Store and Google Play can still feel like a maze of credentials, build artifacts, and store-specific rules. The goal here is not a perfect, frictionless launch. It is a workflow that gets you from an Expo project to signed iOS and Android releases with fewer surprises, plus realistic expectations for approvals, back-and-forth, and occasional delays outside your control.

Everything You Need to Know About Apple and Google Developer Accounts goes deeper on the ideas above and adds concrete next steps.

Early proof: the Expo publishing workflow in one glance

A compact pre-build checklist for Expo app publishing, covering bundle IDs, package names, version numbers, signing, assets, and environment variables before creating store-ready builds.

A simple Expo publishing flow diagram showing app config, EAS Build, App Store Connect upload, and Google Play Console upload, with iOS and Android branches separated after the build step.

• Explanation: This is the end-to-end path I use for Expo releases: lock identifiers, build signed binaries with EAS, upload, then work through store review and rollout.
• Interpretation: Many failures (in my experience) come from identity and signing (bundle ID, package name, certs, keystore) and store readiness (privacy, screenshots, test access).
• Reader impact: If you treat this like a checklist and budget time for account setup, verification steps, and review variability, your first release is far less likely to turn into a multi-day credential scramble.

A concrete example workflow I ship with: Android goes to Internal testing first, then a staged rollout at 10%. I watch Crashlytics or Sentry for crash-free sessions and Play Console for ANR rate for a few hours (or a day if usage is low) before expanding to 50% and then 100%.

When you move from outline to execution, How to Publish a Replit-Built Mobile App helps close common gaps teams hit here.

Why does Expo publishing still trip up teams?

Expo helps you ship product fast, but store publishing is its own discipline: identifiers, signing, metadata, and review rules. This is for teams on managed workflow or prebuild who need a reliable path from working app to first release, or teams who shipped once and then got stuck later because credentials or store settings drifted.

What you should end with is practical: stable identifiers, signed IPA and AAB outputs from EAS, and a routine you can repeat. Effort-wise, first-time setup commonly takes 0.5-2 days of focused work (accounts, screenshots, policies, store forms), and a routine update is often 30-90 minutes plus review time.

One thing worth noting: there are real constraints outside the repo. Apple Developer and Google Play accounts cost money, new accounts can trigger extra verification, and cloud builds can sit in a queue during busy periods.

What usually blocks the release:

• Identifier mismatch between Expo config and store record
• Credential issues during EAS Build (wrong Apple team, expired certs, lost keystore)
• Review delays from missing screenshots, privacy disclosures, or missing test account access
• Versioning mistakes (forgot to bump iOS build number or Android versionCode)

The practical outcome is "publish with fewer surprises", not "guaranteed approval on the first try". App category, permissions (especially background location), and anything touching payments or kids audiences can increase review scrutiny.

A complementary angle worth comparing lives in How to Publish Your Bolt-Generated Mobile App.

How do you publish an Expo app step by step?

1. Prepare the Expo project for store delivery

   Set stable identifiers in app.json or app.config.js: ios.bundleIdentifier for Apple and android.package for Google Play. Changing these later usually means a new app listing, and it can prevent existing users from receiving updates.

   Align basics you will get asked about in review: icons, splash, version, iOS build number, Android versionCode, and only the permissions you actually need. The tradeoff is real: fewer permissions usually means fewer review questions, but it can require product compromises (for example, no background location).

   Pre-build check	Why it blocks submissions
   Bundle ID and package name	Must match the store record exactly
   Version and versionCode	Prevents duplicate uploads and "already used" errors
   Assets and permissions	Common rejection and warning triggers

2. Build and submit (with real commands and decision points)

   For a first run, budget 30-60 minutes for EAS configuration and credential prompts. Budget additional time for external dependencies like Apple enrollment, Google verification, role permissions, and 2FA, since those can stretch the process across days.

   Use these commands as your backbone:

   • eas build --platform ios (outputs IPA)
   • eas build --platform android (outputs AAB)
   • eas submit --platform ios or upload via Transporter (macOS app)
   • eas submit --platform android or upload in Play Console

   Decision points that matter:

   • Google Play track: Internal testing is fastest for validation; production usually benefits from staged rollout (for example 5-20%) to limit blast radius if you missed something.
   • iOS distribution: Use TestFlight first, then submit for review. Some apps move quickly, others do not, and a single rejection can add days.

   Failure modes worth planning for:

   • Apple Developer enrollment or role access delays: If your account is new or your role is wrong, you may be blocked until an Admin fixes it.
   • Play Console verification holds: New or recently changed accounts can be paused for identity or payment verification.
   • Credential recovery timelines: Losing the Apple ID 2FA device or the Android keystore can turn into a days-long unblock. In the worst case, you cannot update the existing Android app without the original keystore.

   Validate before you publish:

   • Install TestFlight and Play internal builds on real devices (not just simulators)
   • Smoke test login, purchases, deep links, notifications, and release-only flags
   • Confirm environment variables are present in the production build (a common "works in dev" failure)

Expo release checklist
Copy a sprint-ready checklist for identifiers, versioning, builds, uploads, and post-launch checks.
Grab the checklist

For tradeoffs, checklists, and edge cases, App Store Connect vs Google Play Console: Key Differences rounds out this section.

What are the common Expo publishing mistakes?

A short release timeline showing the sequence from final test build to submission, review, fix if rejected, and rollout to production for both App Store and Google Play.

Most delays are boring but expensive. A frequent one is an identifier mismatch between your Expo config and what you created in App Store Connect or Play Console, which can break uploads or cause you to accidentally set up a second app record.

The other recurring loop is submitting before privacy disclosures and test access are ready, then getting stuck in reject-fix-resubmit. If your app needs a login, assume you will need to provide a working reviewer account and any setup steps.

One thing worth noting: EAS can manage credentials, but credential ownership and access control is still on you. If the Apple or Google account is owned by a past contractor, plan time to regain access and rotate credentials safely.

Pre-flight checks before hitting submit:

• iOS build is uploaded and visible in App Store Connect under the correct app record
• Android AAB is in the intended Play track and signed as expected
• Screenshots, release notes, privacy policy, and support URL are ready on both listings
• Rollout plan is decided (full release vs staged) and someone is on point to monitor crashes

Need help sanity-checking your first release?
Share your current Expo config and target tracks, and I will point out common credential and store-review risks before you submit.
Get a quick review

Publishing at Every Stage: How App Store Strategy Changes as You Grow reframes the same problem with a slightly different lens - useful before you finalize.