How to Deploy and Distribute a React Native App to the App Store and Google Play (2026 Guide)

From Build to Download: Deploying a React Native App in 2026

A 40% first-submission rejection rate on the App Store, combined with Google Play's August 2026 Android 16 targeting deadline, means the stakes for getting app distribution right have never been higher. Yet most guides treat deployment as a technical afterthought — a checklist of CLI commands that ends at eas submit.

This guide covers the full distribution lifecycle: EAS build configuration, app store optimization (ASO) that lifts installs by up to 35%, rejection prevention, and a cost breakdown comparing EAS against Fastlane and Bitrise. Whether you're shipping a first release or scaling to a production CI/CD pipeline, the sections below give you a structured path from source code to live installs.

Quick answer: Expo EAS handles the full deployment lifecycle — cloud builds, code signing, store submission, and OTA updates — with a free tier covering 15 builds/month per platform. The critical step most teams skip is ASO: 65% of iOS installs come from App Store Search, and rank 1-3 captures 4.6x more installs than positions 8-15.

---

Pre-Launch Checklist (Do This Before Any Build)

Before touching EAS, verify these 10 items. Each rejection wastes 1-7 days of review time.

• [ ] Remove all console.log calls — or wrap them in if (__DEV__). Leaked logs slow production builds and flag review scrutiny.
• [ ] Set version and buildNumber in app.json — version is user-facing (1.0.0), buildNumber is the store increment (integer).
• [ ] Add Privacy Manifest (PrivacyInfo.xcprivacy) — mandatory on iOS since May 2024; absence triggers automatic rejection.
• [ ] Target Android API 36 — Google Play requires API 36 minimum from August 31, 2026, for new submissions and updates.
• [ ] Prepare Privacy Policy URL — both stores require a public URL; no placeholder accepted.
• [ ] Complete Apple Privacy Nutrition Labels — declare data collection categories accurately; mismatches trigger rejection.
• [ ] Configure Data Safety section (Google Play) — discloses data collection, sharing, security practices.
• [ ] Test on real devices — simulator crashes don't always reproduce on physical hardware; Apple rejects apps that crash on review.
• [ ] Set up crash reporting (Sentry, Bugsnag, or similar) — store reviewers test the app live; uncaught errors mean rejection.
• [ ] Prepare App Store assets — 1024×1024 icon, screenshots for every required device size (iPhone 6.7", iPad 13", Pixel 6).

---

EAS Setup: Credentials, Build Profiles, and Submission

Expo Application Services (EAS) handles cloud builds and code signing so you don't manage keystores and provisioning profiles locally. The setup takes under an hour.

1. Initialize EAS in Your Project

npm install -g eas-cli
eas login
eas init --id your-app-id

EAS creates a project ID in your app.json and links it to your Expo account. You get 15 free iOS and 15 free Android builds per month on the Free plan.

2. Configure eas.json Build Profiles

A three-profile setup covers the full release pipeline:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal",
      "ios": { "simulator": false },
      "android": { "buildType": "apk" }
    },
    "production": {
      "autoIncrement": true,
      "android": { "buildType": "app-bundle" },
      "ios": { "credentialsSource": "remote" }
    }
  },
  "submit": {
    "production": {
      "ios": {
        "appleId": "your@email.com",
        "ascAppId": "1234567890"
      },
      "android": {
        "serviceAccountKeyPath": "./service-account.json",
        "track": "production"
      }
    }
  }
}

Key decisions:
- autoIncrement: true — EAS bumps the build number automatically; you never need to do it manually.
- credentialsSource: "remote" — EAS manages iOS signing certificates in its secure vault; safer than local management.
- buildType: "app-bundle" — Google Play requires AAB for Play Store distribution; APK is only for direct sideloading.

3. Build and Submit in One Command

# Build and submit to both stores simultaneously
eas build --platform all --profile production
eas submit --platform all --profile production

Typical build times: 8-15 minutes (Android), 10-20 minutes (iOS). After eas submit, your binary lands in App Store Connect (iOS) or Google Play Console (Android) automatically.

---

App Store Optimization: The Step Most Teams Skip

Getting listed is only half the job. According to a 2026 analysis of ASO benchmarks, 65% of iOS installs come from App Store Search — making keyword ranking as important as the code itself.

Keyword Strategy

Apple allocates 100 characters for keywords (separate from the name and subtitle). Google Play uses the full description for keyword indexing. Both reward precise relevance over keyword stuffing.

What moves ranking:
- Rank 1-3 captures 4.6x more installs than positions 8-15 (digitalapplied.com, 2026)
- Apps in the top position receive approximately 34% of daily search installs for that term
- Positions 31+ contribute less than 4% of search-driven installs

Practical keyword process:
1. Research 20-30 candidate keywords using AppFollow, AppTweak, or the free Appfigures keyword tool
2. Classify by difficulty: prioritize medium-volume, low-competition terms your app can realistically rank for
3. Fill the iOS 100-character keyword field without spaces between terms: project,management,task,tracker,team,collaboration,kanban
4. In your Google Play long description, use each target keyword 3-5 times naturally within real sentences

Screenshot Optimization

60% of users never scroll past the first two screenshots (AppDrift, 2026). Your first screenshot is your conversion billboard.

What the data says:
- Optimized screenshots with text overlays and clear value propositions deliver 25-35% higher conversion rates
- The median conversion lift from winning screenshot A/B tests is 11.8%
- iOS Custom Product Pages deliver 18-26% conversion lift over the default page

Screenshot rules that move the needle:
- First screenshot: lead with the core benefit, not the UI ("Book appointments in 30 seconds" over a blank calendar view)
- Use portrait format for lifestyle apps, landscape for productivity tools
- Localize captions — apps with 10+ market localizations see 35-50% higher conversions
- Test at least 3 creative variants before settling; Apple's Product Page Optimization supports up to 3 treatments

Ratings Strategy

Apps with 4.5+ star ratings install at 1.7x the rate of apps under 4.0. Moving from 3 stars to 4 stars correlates with a 340% revenue increase (AppDrift benchmarks, 2026).

The trigger matters as much as the prompt:
- Request a review after a clear success moment (completed task, successful booking, achievement unlocked)
- Use StoreReview.requestReviewAsync() from expo-store-review — Apple limits prompts to 3 times per 365-day period
- Never prompt after a crash, failed payment, or error — negative reviews follow negative experiences

---

OTA Updates With EAS Update: When to Use Them

Over-the-air (OTA) updates push JavaScript and asset changes directly to users, bypassing the 24-48 hour App Store review cycle. They don't work for native code changes (new dependencies, config changes, native module additions).

Use OTA for:
- Bug fixes in JavaScript logic
- Copy and content changes
- UI tweaks and style changes
- A/B testing feature flags in JS

Require a full store build for:
- New native dependencies (expo install for native modules)
- Changes to app.json (icons, splash, permissions)
- Privacy Manifest updates
- SDK upgrades (e.g., Expo SDK 53 → 54)

# Deploy an OTA update to production channel
eas update --branch production --message "Fix checkout crash on Android"

EAS Update routes users on the production channel to the latest compatible update within their runtime version. This means a user on SDK 53 only receives updates built for SDK 53 — they won't receive updates targeting SDK 54 until they upgrade through the store.

---

The 40% Rejection Problem: What Gets Apps Rejected

Apple rejected approximately 25% of all 7.77 million submissions reviewed in 2026 — with first-time submissions hitting a ~40% rejection rate. Google Play's automated review rejects 10-15%, but enforcement of Data Safety violations is aggressive.

The most common rejection pattern by cause:

Cause	Platform	Prevention
App Completeness (Guideline 2.1)	iOS	Test every screen; no placeholder content
Missing Privacy Manifest	iOS	Add PrivacyInfo.xcprivacy before first build
Privacy Nutrition Label mismatch	iOS	Audit all third-party SDKs for data collection
API 36 non-compliance	Android	Upgrade compileSdkVersion and test
Misleading screenshots	Both	Screenshots must match actual app functionality
Incomplete Data Safety declaration	Android	Disclose all data collection including analytics

The GDPR consideration for EU distribution: If your app collects any personal data from EU users (which includes analytics SDKs like Firebase), your privacy policy must comply with GDPR. App Store Connect and Google Play require a public privacy policy URL — not a PDF, not a "coming soon" page, and not an auto-generated boilerplate. Real legal review costs €200-800 from a GDPR-focused law firm; template services like iubenda cost €27-69/year. Factor this into your launch budget.

---

Staged Rollouts and Release Management

Shipping to 100% of users on day one amplifies crashes you haven't found yet. Both stores support staged rollouts; use them.

Google Play staged rollout: In the Google Play Console, choose "Release to a percentage of users" and set your initial rollout to 5-10%. After 48-72 hours of clean metrics, advance to 20%, then 50%, then full. This has zero additional cost and catches production issues before they hit your entire user base.

Apple App Store phased release: In App Store Connect, the 7-day phased release distributes at: 1% → 2% → 5% → 10% → 20% → 50% → 100%. You can pause at any phase. The limitation: phased release applies only to automatic updates, not manual downloads — users who search for your app always get the latest version regardless.

Version naming that prevents confusion: Use semantic versioning consistently — MAJOR.MINOR.PATCH (e.g., 1.3.2). The build number (internal) increments with every submission; EAS handles this automatically with autoIncrement: true. Where teams go wrong: incrementing the user-facing version for every build, producing a confusing 1.0.47 visible in the App Store for what users perceive as a basic new app.

---

iOS vs Android: Key Differences That Cause Submission Delays

Building for both platforms in parallel is seamless until submission, where the review processes diverge significantly.

Factor	iOS App Store	Google Play
Review type	Manual human review	Automated + spot manual
First-time review	3-7 days	1-3 days
Update review	24-48 hours	Hours to 1 day
First-submission rejection rate	~40%	~10-15%
Annual developer fee	$99/year	$25 one-time
Minimum SDK target (2026)	iOS 16+	API 36 (Aug 31)
Sideloading	EU only (DMA)	Allowed globally
Privacy requirements	Privacy Manifest + Nutrition Labels	Data Safety declaration

The iOS Privacy Manifest is the single most common cause of first-submission rejections in 2026. Every app using Apple's Required Reason APIs — UserDefaults, FileTimestamp, SystemBootTime, DiskSpace, and others — must declare usage in PrivacyInfo.xcprivacy. Third-party SDKs (Firebase, Sentry, Amplitude) that access these APIs need their own manifests too. Run npx expo-doctor before building to surface missing declarations.

The Android API 36 deadline (August 31, 2026) means any update after this date must target API 36. Practically: update compileSdkVersion in android/build.gradle and test on an Android 16 emulator (Pixel 6 or higher) before your next release cycle.

---

CI/CD: Automating Deployments With GitHub Actions + EAS

Manual eas build commands don't scale beyond a team of two. The EAS Workflows system (plus GitHub Actions) automates the full pipeline.

A minimal GitHub Actions workflow for production releases:

name: EAS Production Build
on:
  push:
    tags:
      - 'v*'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: eas build --platform all --profile production --non-interactive
      - run: eas submit --platform all --profile production --non-interactive

This triggers a production build and submission on every version tag push (v1.2.3). The --non-interactive flag is required for CI environments; it fails loudly on missing credentials rather than prompting.

For PR preview builds, EAS Workflows lets you automatically generate a preview APK/IPA link on every pull request — reviewers can install the exact build being reviewed without needing a development environment.

---

Cost Breakdown: EAS vs Fastlane vs Bitrise

No guide compares these honestly. Here's what you'll actually pay:

Approach	Build Cost	Monthly Cost	Setup Time	Best For
EAS Free	15 builds/platform	$0	1-2 hours	Indie / early-stage
EAS Starter	$1-4/build	$19	1-2 hours	Small teams, 1-2 apps
EAS Production	Credits included	$199	1-2 hours	Multiple apps, CI/CD
Fastlane (self-hosted)	$0 (your CI minutes)	GitHub Actions free tier or $8/month	8-16 hours	Teams with DevOps experience
Bitrise	$0.01-0.05/min	$39-399	4-8 hours	Large teams, advanced CI

When EAS wins: You want zero configuration overhead, managed code signing, and fast time-to-first-release. For most React Native teams under 5 developers, the $0-19/month range covers everything.

When Fastlane wins: You're already running your own CI infrastructure (GitHub Actions, GitLab CI) and want zero platform dependency. Fastlane's match handles certificates and deliver handles submission — but someone on your team has to maintain the Ruby configuration.

When Bitrise wins: You need a dedicated mobile CI platform with built-in caching, device testing, and on-call support. The premium pricing is justified only for teams shipping multiple apps at high frequency.

---

When NOT to Use EAS (4 Scenarios)

1. You have existing Fastlane workflows — migrating to EAS mid-project creates certificate conflicts and CI disruption. If Fastlane works, optimize it instead of switching.

2. You use extensive custom native modules with complex signing — EAS's remote credential management sometimes conflicts with enterprise distribution certificates and provisioning profiles for highly customized native setups. Local builds with eas build --local are the workaround.

3. You're distributing an enterprise-only app (no public App Store listing) — Apple Enterprise Program ($299/year) has specific distribution requirements that work better with MDM-based deployment than EAS.

4. Your builds take 30+ minutes — EAS's free tier builds are low-priority (queued behind paid builds). If your monorepo builds consistently take 25-40 minutes, you'll burn through free tier credits quickly. Run eas build --local for development and save cloud builds for production releases.

---

Frequently Asked Questions

How long does it take for an app to be approved on the App Store?

First-time submissions take 3-7 days. Updates to existing apps typically clear in 24-48 hours. Apple reviews manually; you can request an expedited review through App Store Connect for critical bug fixes, though approval of the request isn't guaranteed.

Does EAS work with bare React Native projects (non-Expo)?

Yes. EAS Build supports bare React Native projects created with npx react-native init. You install expo-modules-core and configure eas.json without migrating your full project to the Expo managed workflow.

What's the difference between EAS Build and EAS Submit?

EAS Build compiles your app binary in the cloud (APK/AAB for Android, IPA for iOS). EAS Submit takes a completed binary and uploads it to App Store Connect or Google Play Console on your behalf. You can use EAS Submit to upload a binary built elsewhere — the two services are independent.

How often should I publish OTA updates vs full store releases?

A practical rule: OTA for JavaScript-only fixes and copy changes (can deploy daily), full store releases for anything touching native code or configuration (aim for bi-weekly sprints). Don't use OTA to sneak feature changes past store guidelines — Apple and Google review apps periodically post-launch and reject apps that deviate from approved functionality.

What happens if my app is rejected after submission?

Apple sends a rejection notice with the specific guideline violated. Log into App Store Connect → My Apps → Resolution Center to respond or submit a revised binary. You can resubmit after fixing the violation — there's no penalty for first-time rejections. For urgent issues, you can request an appeal via the App Review Board.

Do I need a separate Apple Developer account for each app?

No. One Apple Developer account ($99/year) supports unlimited apps and up to 100 TestFlight testers per app. Google Play charges a one-time $25 fee per developer account, also supporting unlimited apps.

How do I handle different environments (dev/staging/production) in EAS?

Use EAS Build profiles in eas.json combined with APP_ENV environment variables to control which API endpoint and feature flags each build targets. EAS Dashboard's "Environment Variables" section lets you store secrets per-profile without hardcoding them in your repository.

What ASO metrics should I track after launch?

Monitor four signals weekly: (1) Keyword ranking position for your top 10 target terms, (2) Tap-through rate (TTR) in App Store Connect / Play Console — benchmark against the 33.4% iOS median, (3) Install conversion rate — below 15% typically means screenshots or description need work, (4) Rating trajectory — velocity matters; 12+ reviews per 1,000 installs is the threshold for stable average rating.

---

Launching vs. Distributing: The Long Game

Submitting to the stores is the starting line, not the finish. Apps that grow organically invest as much in post-launch distribution — ASO iteration, review response, OTA update cadence — as in the initial release.

The React Native stack makes this manageable: EAS Update ships JavaScript fixes in minutes, Custom Product Pages let you A/B test store listings without a code change, and expo-store-review prompts users at the right moment to sustain your rating above 4.5.

If you're building a React Native app and need help with production deployment, CI/CD configuration, or post-launch ASO strategy, our mobile development team can scope a deployment setup or take over the full launch process.

For deeper context on the development side, see our guides on React Native app architecture, performance optimization, testing best practices, and mobile app MVP cost breakdown.