React Native App Store and Play Store Release Checklist

Accounts, identity and signing

Release work starts long before the first submission. Create the Apple Developer and Google Play Console accounts in the client's company name early, because verification can take time and the client should own the store listings. Decide the bundle identifier and package name once, since they cannot be changed after publishing. Set up app signing carefully. Google Play App Signing and Apple's certificate system both protect your app, and losing signing keys can block future updates.

Store credentials and signing material in a secure shared location with restricted access, not on one developer's laptop. If you use Expo EAS, it can manage credentials for you; with a bare project, follow the official Android and Apple signing guides. Document who owns each account and how to rotate access when team members leave. Agencies that build apps for clients should transfer or share ownership formally at handover.

Pre-release checklist

Run a written checklist before every release rather than relying on memory. Many store rejections come from simple omissions: a missing privacy policy link, a permission prompt with no clear explanation, a demo account the reviewer cannot use or a broken link in the store description. Review the current App Store Review Guidelines and Google Play policies before your first submission, and again before major releases, because requirements change.

Prepare store listing content early, because it often depends on people outside the development team. Marketing may need to write descriptions, designers must produce screenshots in the required sizes, and legal or compliance staff may need to approve the privacy policy. If the app serves several countries, plan localised listings, for example English and Hindi for India or English and Arabic for the Gulf. Starting late on these items is a common reason a finished app waits weeks for launch.

• Version number and build number incremented
• Production API URLs, analytics and crash reporting configured
• Every permission has a clear purpose string
• Privacy policy URL live and data safety or privacy labels completed
• Reviewer demo account and notes provided
• Screenshots, description and support URL up to date
• Release build tested on a low-end Android phone and a recent iPhone
• Push, deep links and payments tested from the test matrix

Building and submitting

Build signed production versions in CI or with a cloud build service so every release is reproducible. The illustrative commands below use Expo's EAS services. Bare projects use Gradle for Android and Xcode or Fastlane for iOS. Whatever the tool, keep build profiles in version control so staging and production builds are configured the same way every time, and tag the commit that produced each release.

Write clear release notes for each version, both for the store listing and for the client. Store notes should describe user-visible changes in plain language. Internal notes should list the commit, the build numbers, the backend version it expects and any configuration changes. If a release depends on a backend change, deploy the backend first and make sure it stays compatible with older app versions, because many users update slowly or never.

# Illustrative EAS commands. See docs.expo.dev/build and
# docs.expo.dev/submit for current options and eas.json setup.

# Production builds for each store
eas build --platform android --profile production
eas build --platform ios --profile production

# Upload the finished builds to the stores
eas submit --platform android
eas submit --platform ios

# Bare projects: build signed release artifacts with Gradle
# and Xcode instead, following the platform guides.

Testing tracks, staged rollout and after launch

Use the testing tracks both stores provide. TestFlight on iOS and internal, closed and open testing tracks on Google Play let you distribute builds to testers before public release. Invite the client's team and a few real users. Check the current Google Play requirements for new developer accounts, which may include a closed testing period before production access. Collect feedback through a simple form and fix blocking issues before going live.

When you release, use staged rollouts where available so a new version reaches a small share of users first. Watch crash reports, reviews and key metrics for a day or two before expanding. Over-the-air update services can ship JavaScript-only fixes quickly, but use them within the store rules and never to add features that would change what reviewers approved. XDQ Labs teams keep a short post-release log for each version, noting issues and fixes for the next cycle.

Check your understanding