Back to Insights

App Publishing · Published 2026-08-15 · 6 min read · Waris Labs

How to Prepare a React Native App for Google Play Production

A practical production checklist for React Native Android apps covering release builds, versioning, signing, testing tracks, privacy, data safety, and Play Console readiness.

Published by Waris Labs, a software engineering studio publishing practical guides on React Native, Firebase, cloud systems, app publishing, and AI automation.

Waris Labs Insights are educational technical notes. Verify platform requirements, security impact, and production behavior before applying code or configuration changes.

Getting a React Native app into Google Play production is not just a build command. The release can be delayed by signing mistakes, version code conflicts, incomplete policy forms, crashy release builds, missing privacy pages, or a store listing that is not ready for review.

The best release process treats Google Play submission as a production workflow. The app binary, Play Console setup, legal pages, and test evidence all need to line up.

Key Takeaways

  • Google Play production readiness depends on the binary, signing, versioning, test tracks, privacy/data safety answers, and store listing being consistent.
  • A release build must be tested separately from debug mode because React Native production artifacts behave differently.
  • Some Google Play requirements are official platform rules; other checklist items are Waris Labs recommendations for reducing launch risk.
  • Use internal or closed testing to validate the exact artifact and keep release notes tied to commit hash, version code, and known risks.

Confirm the Release Configuration

Start with the Android package name. Once an app is published, the package name is effectively the product identity on Google Play. Confirm it before the first upload:

{
  "expo": {
    "android": {
      "package": "com.example.fitness",
      "versionCode": 12
    },
    "version": "1.4.0"
  }
}

For plain React Native projects, the same idea lives in Gradle configuration. The important point is that every production upload must have a higher versionCode than the previous upload for the same package. The user-facing versionName or Expo version should also be meaningful, but Google Play uses version code ordering to decide upgrade paths.

Build the Right Artifact

Google Play expects Android App Bundles for new apps. An .aab is not the same as an APK you install manually. The bundle contains compiled code and resources, and Google Play generates optimized APKs for user devices. Android's own documentation explains the format here: About Android App Bundles.

For Expo projects, use the production build profile that matches your release process. For React Native CLI projects, build a signed release bundle from Gradle. Do not upload a debug build, a local development build, or an artifact signed with the wrong key.

Understand Signing and Play App Signing

Signing mistakes are one of the fastest ways to lose a release day. With Play App Signing, Google Play manages the app signing key used for final APKs delivered to users. You keep an upload key that signs the bundle before upload. Google verifies that upload and then signs distribution artifacts.

Google's Play App Signing guide explains the key split in detail: Use Play App Signing.

For apps that use Google APIs, OAuth, Firebase Dynamic Links, Android App Links, Maps, or similar services, remember that the fingerprint users receive may be the Play app signing certificate, not only your local upload key. Register the correct SHA-1 or SHA-256 fingerprints with those providers.

Test the Release Build, Not Only Debug

Debug builds are forgiving. Release builds are optimized, minified, signed, and bundled differently. React Native release builds can reveal problems hidden during development:

  • Missing native permissions
  • R8 or ProGuard stripping classes
  • Hermes stack traces that need symbolication
  • Native dependency ABI issues
  • Incorrect API host configuration
  • Images or assets missing from the bundle
  • Crashes that only happen without Metro

React Native's publishing guide recommends testing the release build before upload: Publishing to Google Play Store. For crash triage, see Common React Native Android Production Crashes and How to Debug Them.

Use Internal Testing First

Internal testing is the fastest way to get a Play-distributed build onto real devices. It helps confirm the bundle installs, the signing path works, and Google Play can serve the artifact.

Use internal testing for:

  • First install and upgrade testing
  • Login, logout, and account deletion flows
  • Push notification checks
  • Payment or ad consent checks
  • Device compatibility checks
  • Store-distributed build smoke testing

Google's Play Console help describes internal, closed, open, and production releases here: Prepare and roll out a release.

Closed Testing May Be Required

Some developer accounts, especially certain newer personal accounts, may need to complete closed testing requirements before production access. Do not present one account's requirement as universal for every developer account, because Play Console requirements can vary by account type, region, history, and current Google policy.

When closed testing is required, plan for it early. The practical work is not only uploading a build. You need testers, opt-in links, feedback collection, enough time, and a stable enough product to survive real use.

The differences between testing tracks are covered in Google Play Internal Testing vs Closed Testing vs Production.

Prepare Privacy and Data Safety

If the app collects, stores, shares, or processes user data, the privacy policy and Data safety answers must match reality. A fitness app is especially sensitive because it may involve health-related behavior, body metrics, nutrition, location, identifiers, or account data.

Before submission, verify:

  • Privacy policy URL is public and not blocked by authentication.
  • Account deletion instructions work if accounts exist.
  • Data safety answers match SDK behavior.
  • Analytics, crash reporting, ads, and push notifications are included.
  • Permission prompts are explainable from app behavior.

Do not treat the Data safety form as marketing copy. Treat it as a technical inventory of what the app and SDKs actually do.

Store Listing Readiness

A production-ready store listing should set the right expectation before review:

  • App name and short description match the actual product.
  • Screenshots show real screens, not temporary mockups.
  • Feature graphic meets Play requirements.
  • Category and tags are accurate.
  • Contact email works.
  • Support and privacy URLs are live.
  • Test credentials are provided if review needs login.

If the app is unfinished, the listing will make that obvious. Empty screens, temporary screenshots, broken links, or vague descriptions can slow down review and reduce user trust.

Crash Testing Checklist

Before pushing to production, run the release build through real flows:

  1. Fresh install
  2. Upgrade from previous version
  3. First launch without network
  4. Login and logout
  5. Password reset
  6. Main create/edit/delete flow
  7. Notification tap
  8. Deep link open
  9. App restart after backgrounding
  10. Account deletion or support flow

If your app includes local notifications, test the app after it is backgrounded and terminated. The notification lifecycle details are covered in How Local Notifications Work in React Native When the App Is Closed.

Common Reasons Releases Get Delayed

Common blockers include:

  • Version code not incremented
  • Wrong signing key or missing upload key
  • Missing privacy policy
  • Data safety mismatch
  • App crashes on launch in release mode
  • Login required but no review credentials provided
  • Sensitive permission without clear user benefit
  • Broken account deletion link
  • Incomplete closed testing requirement
  • Native library compatibility issue

The best prevention is a repeatable release checklist saved in the repo. Include commit hash, build number, environment, tester notes, known risks, rollback plan, and Play Console track.

Official Documentation

Conclusion

Preparing a React Native app for Google Play production means aligning the binary, signing, test track, policy forms, privacy pages, and real-device behavior. Build the release artifact intentionally, test it outside the dev server, use internal or closed testing where appropriate, and fix policy-sensitive surfaces before review. That discipline turns Play submission from a guessing game into a predictable release process.

Related Articles