Android App Publishing with Expo: A Complete Guide

You've got the app working on your phone, the Expo build is solid, and now the part that feels annoyingly real has arrived, getting it into Google Play without falling into a Gradle rabbit hole. If you already know your way around Expo and React Native, the good news is that you can stay mostly in EAS Build, eas.json, and Play Console, and avoid the native Android Studio maze unless something breaks.

Table of Contents

• Where You Stand Before Publishing
• Preparing Your Expo App for Release
  • Lock the release identity first
  • Clean up the assets and privacy surface
• Generating Signed Builds with EAS
  • Set up Play signing and your EAS profile
• Uploading and Configuring Your Play Console Release
  • Pick the right track for the first upload
  • Fill the listing before you chase production
• Choosing a Rollout Strategy That Fits Your Team
  • Use the smallest audience that gives you signal
  • Read rollout as signal collection
• Automating with CI/CD and Fixing Common Errors
  • Connect the build and submit steps
  • Fix the failures you'll actually hit
• Policy, Store Listing, and Your Pre-Submit Checklist
  • Tighten the listing before you submit
  • Run the final checklist

Where You Stand Before Publishing

You are not starting from zero. Your Expo app already runs on a device, so the job now is to turn that working project into a release path that does not get derailed by store details. Treat android app publishing as a sequence of gates, not a single button click, because Play Console checks the build artifact, the listing, the testers, and the policy forms before it lets anything move forward.

The practical path stays the same for Expo and React Native teams that want to avoid the Android Studio rabbit hole. First, make the app release-ready in your Expo config and eas.json. Then produce a signed Android App Bundle with EAS Build, upload it to Play Console, and pass through testing before production. That keeps you in the Expo workflow while still giving Google the release format and console setup it expects.

Crowded stores reward disciplined releases. Google Play is still full of active apps and publishers, and the latest tracking data from 42matters shows how much volume sits in the system, which is exactly why release discipline matters in practice, not just in theory. Google's own publishing guidance also frames success around install base, meaning the number of active devices an app is installed on, with an active device defined as one turned on at least once in the previous 30 days. That is the right mental model for launch planning, because visibility is not the finish line, sustained device reach is.

A three-step flowchart showing the process of building, testing, and publishing an Android mobile application.

If you want a quick refresher on the Expo setup before you start, AppLighter's Expo getting started post is a useful companion, especially if you want to confirm that your project structure already fits a clean release workflow.

Preparing Your Expo App for Release

Release prep in Expo is mostly config work, but the details matter because Play Console uses them to distinguish one submission from another and to judge whether the app looks trustworthy. The fastest way to waste time is to build too early, then discover the bundle is rejected for avoidable metadata or permission issues.

Lock the release identity first

Start in app.json or app.config.ts. Bump the version for humans, and bump android.versionCode for Play Console, because every upload needs a unique internal identifier. In Expo projects, that usually lives beside your Android package name, icon, and splash config, so it's worth reviewing the whole block before you touch EAS.

Practical rule: if a build is meant for Play Console, its version code should never be the same as the last uploaded one.

Next, trim your permissions. Expo and React Native apps often accumulate permissions during development, especially if you've tested camera, location, notifications, or media access. Keep only what the app uses in release, because Android users notice overreaching prompts quickly, and Play reviewers do too.

Clean up the assets and privacy surface

Use proper adaptive icons and splash screens, not just a square logo dropped into a placeholder. Expo's asset tooling can generate the needed Android-friendly imagery, and that gives your listing and launch screen a much more polished feel. If your app targets newer Android behavior, make sure your privacy-related declarations are current in your project config and Play Console fields, especially if your app handles sensitive data or background access.

A quick OTA-safe preflight is worth doing before any binary build. Run the app through a normal development or preview path, confirm navigation, authentication, and network flows still behave with the latest config, then check that the release version won't surprise you at upload time. If you skip this, you end up debugging a build artifact instead of a code path, which is always slower.

A simple checklist works well here:

• Version fields: confirm the release version and android.versionCode are incremented.
• Permissions: remove anything the app doesn't need.
• Icons and splash: verify the Android assets render cleanly.
• Config integrity: inspect app.json or app.config.ts for stale values.
• Release behavior: test the latest build path locally before handing it to EAS.

Generating Signed Builds with EAS

The right artifact for Google Play is an AAB, not a raw APK. App Bundles let Play generate device-specific delivery packages, which is the publishing path Google wants for modern releases, while APKs remain a separate distribution route that's more useful for direct sharing than for Play submission. Google's app bundle guidance also makes clear that Play handles optimized APK generation and signing behavior for bundle-based publishing, which is why Expo developers should prefer this route for the store.

Set up Play signing and your EAS profile

Turn on Play App Signing in Play Console so Google manages the app signing key. That leaves you with a local upload key, which is the key EAS uses to sign the bundle before upload. In practice, that reduces the amount of key management you need to keep under your own control.

Your eas.json production profile should point at an Android app bundle build. A typical setup looks like this in spirit, even if your project has its own naming conventions:

• Profile name: production
• Android build type: app-bundle
• Distribution: store

That combination tells EAS to generate the artifact Play Console expects, not a sideloading artifact. If you need a cost sanity check before you build repeatedly, this EAS Build cost guide is useful context, especially for teams that iterate a lot on release candidates.

Run the build from the terminal:

eas build --platform android --profile production

When it finishes, confirm that the output is a signed .aab and that it matches the production profile you intended. If you're unsure whether the signing path is correct, keep the upload key details in order and avoid mixing local debug keystores with release credentials.

A good mental model is simple. If the build is meant for Play Console, it should be reproducible from your Expo config, signed for upload, and stored with the same release profile every time. That consistency is what keeps publishing boring in a good way.

If you prefer a visual overview of this build flow, the embedded walkthrough below is a handy companion while you wire up the first production profile.

Uploading and Configuring Your Play Console Release

Once the AAB exists, the next job is to get it into the right Play Console track with a listing that doesn't look half-finished. If the app entry doesn't exist yet, create it first, then fill in the store listing fields before you get distracted by rollout settings or tester emails.

Pick the right track for the first upload

Play Console gives you several paths. Internal testing is the fastest way to validate a build with a small group, closed testing is for a curated tester list, open testing is a wider beta, and production is the public release track. For a first-time Expo publish, internal testing is the least stressful place to land because it lets you verify the bundle, install flow, and listing metadata before real users see it.

Upload the bundle to the selected track, then create a release. In that release flow, Google asks for release notes and lets you review the artifact before you proceed. If the app has never been published, the track you choose is less about status and more about control over who can install it and when.

Fill the listing before you chase production

Treat the store listing as part of the release, not a separate marketing task. Add the app name, short description, full description, icon, screenshots, category, and any required contact details. If you're missing those assets, the app will look incomplete even if the build itself is valid.

For testers, Play Console supports email-based access. Add the tester accounts, then share the opt-in link so they can join the track and install the build. That part sounds trivial until someone forgets to accept the invite, which is why I always verify the tester list before I trust the feedback.

The first upload is usually about proving that your packaging, listing, and account permissions all work together. The second upload is the one that starts to feel routine.

Choosing a Rollout Strategy That Fits Your Team

Rollout strategy should match your team size and risk tolerance, not some idealized launch playbook. A solo Expo developer shipping an MVP doesn't need the same approach as a mature team with QA, support, and telemetry already in place.

Use the smallest audience that gives you signal

Internal testing is the fastest feedback loop. It's ideal when you want to confirm that a fresh build installs correctly, signs cleanly, and behaves the same outside your local machine. Closed testing makes sense when you want a controlled group to catch product issues before broad exposure. Open testing is broader and better for public beta energy, but it also creates more noise.

For an MVP, a sensible sequence is internal track first, then a small closed test group, then a staged production rollout. I'd keep the first public production release cautious, because the goal is to observe real device behavior, not prove bravery. Android publishing is measured against active devices on a rolling 30-day basis, so a gradual rollout gives you time to collect meaningful feedback instead of staring at a single launch-day spike.

Read rollout as signal collection

A staged release is useful because it turns publishing into a controlled experiment. If the app is stable, the rollout can widen. If crashes, login failures, or payment issues show up, you've limited the blast radius.

The Play Console track you choose should answer one question, who do you want to expose to risk right now? Internal testing answers, “my team.” Closed testing answers, “my testers.” Production answers, “everyone.” That framing makes decisions much easier when you're tired and staring at the release dialog.

A visual guide explaining different Android app rollout strategies including internal, closed, and open testing methods.

Automating with CI/CD and Fixing Common Errors

Manual publishing works once, then it turns into overhead. Once your Expo app has a repeatable release flow, EAS Submit is the clean path from a finished build into Play Console, and it's the point where you stop clicking through the same upload screens every release. That matters even more if you want reducing time to market in 2026 to show up in your actual ship cadence, not just in planning docs.

Connect the build and submit steps

A practical CI chain starts with eas build --platform android --profile production, then passes the artifact to eas submit. In GitHub Actions or another pipeline, the job can build, sign, and submit without someone sitting in front of the terminal.

Keep the production profile stable and let automation handle the repetitive work. If your team already uses a release checklist, wire that checklist into the pipeline so the same steps run every time without the manual delay. That fits well with a CI/CD workflow for mobile apps once you move past one-off publishing and start shipping on a cadence.

Fix the failures you'll actually hit

Version code conflict. The upload gets rejected because the version code was already used. The cause is straightforward, you reused a build number. Update android.versionCode and rebuild.

Signing certificate mismatch. The upload fails to validate against the Play signing setup. The cause is usually a mismatch between your upload key and what Play expects. Make sure you are using the correct upload keystore and that Play App Signing is configured the same way in the console and in your build setup.

Closed testing stall. The app looks ready, but production access never opens. On new personal accounts, the blocker is the closed-testing gate. Official Google Play guidance for personal accounts requires a minimum of 12 testers who opt in and stay active for 14 consecutive days before production access is granted, so recruit those testers early and check that they install and use the build.

Release not eligible for production. The publish button stays blocked. The usual causes are incomplete testing, missing listing data, or a policy gate you have not finished. Go back through the track requirements, finish the missing pieces, then try again.

Policy, Store Listing, and Your Pre-Submit Checklist

Treat policy as a launch requirement, not legal wallpaper. If you ship an Expo app on Android, the Play Console checks your target API level posture, your Data safety form, your privacy policy URL, and any special-category disclosures for ads, health, or financial behavior. That's where many otherwise solid releases get delayed, because the app is technically ready but the paperwork is not.

Tighten the listing before you submit

Your store listing should match the actual app behavior. If you collect account data, location, or analytics, the privacy policy and Data safety entries need to agree with what the app really does. If the app has ads, health features, or financial flows, review those details carefully instead of guessing at the form answers.

A polished listing also reduces the chance that your first public impression feels rushed. If you're still refining launch creative, an AI app promo video tool like ShipTeaser's app promo video maker can help you package the app for a cleaner store presence without turning the release process into a design project.

Run the final checklist

Before you hit submit, verify these items in order:

• Store listing complete: description, screenshots, icon, and category are filled in.
• Content rating done: the questionnaire is finished and saved.
• Data safety form accurate: it matches actual data collection and sharing.
• Tester access confirmed: if you're on a personal account, the closed-testing requirement is satisfied.
• Signing key verified: the upload path matches the Play App Signing setup.
• versionCode incremented: the uploaded bundle is newer than the last one.

The first publish always feels like the hard one because every step is new. After that, the process turns into a release routine, and that's exactly where you want to be.

---

If you want a faster path from Expo project to Play-ready release, AppLighter gives you a production-oriented starter built for shipping, not tinkering. It's a strong fit when you want to spend less time wiring the same mobile foundations and more time getting your app through Play Console with confidence. Visit AppLighter and use it as the base for your next Expo release.