A React Native release is ready when it has been tested as a real product, not merely compiled successfully. This production readiness checklist gives you a repeatable way to review architecture, performance, security, observability, CI/CD, device behavior, accessibility, and store submission before release—and to estimate where release risk remains.
Overview
Use this checklist during release planning, before a beta build, and again before submitting to the stores. It is designed for both Expo projects and React Native applications with native Android or iOS code. The exact commands will vary according to your setup, but the review questions remain useful across projects.
Start by dividing checks into three groups:
- Release gates: items that must be complete, such as production signing, crash reporting, authentication behavior, privacy disclosures, and tested critical user journeys.
- Risk reducers: improvements that reduce failures or support costs, such as performance profiling, offline handling, accessibility review, and automated regression tests.
- Follow-up work: known limitations that are documented, assigned, and acceptable for the intended release.
A simple readiness estimate can make an otherwise subjective review more consistent. Create a list of checks, mark each one as complete, in progress, blocked, or not applicable, and identify which checks are release gates. A high completion percentage is not enough if a critical gate is still blocked.
For build automation and environment management, pair this checklist with the React Native CI/CD guide. For runtime profiling, see the React Native performance optimization checklist.
How to estimate production readiness
Build a release score from evidence rather than confidence. A practical method is to assign each check a status value:
- Complete: 1 point. There is a test result, build artifact, configuration review, or other evidence.
- In progress: 0.5 points. Work exists but has not been verified in the release candidate.
- Blocked or missing: 0 points.
- Not applicable: exclude the check and reduce the total number of possible points.
Calculate the basic readiness percentage as:
Readiness percentage = completed-equivalent points ÷ applicable points × 100
Then apply a gate review. A release should not be treated as ready if a critical item is incomplete, regardless of the percentage. You can also add a risk count:
Open risk count = blocked critical checks + unresolved high-impact defects + unverified release environments
This estimate is not a quality score or a guarantee of store approval. It is a decision tool for comparing release candidates and exposing gaps. Keep the checklist in version control or in the same project workspace as your release notes so that every status has an owner and a date.
Recommended checklist areas
- Architecture: navigation boundaries, state ownership, error handling, environment configuration, and native module dependencies are documented.
- Testing: critical journeys have unit, integration, or end-to-end coverage appropriate to their risk. Tests run against the release configuration, not only the development server.
- Performance: slow screens, large lists, startup behavior, image handling, unnecessary renders, and memory use have been profiled on representative devices.
- Security: secrets are excluded from the repository, sensitive data is handled deliberately, authentication expiry works, and logging does not expose tokens or personal data.
- Observability: crashes, failed requests, important user actions, and release versions can be identified without collecting unnecessary information.
- Build and delivery: Android and iOS credentials, environment variables, version numbers, signing, artifact storage, and rollback or hotfix procedures are documented.
- Device behavior: permissions, notifications, deep links, camera or location features, network transitions, background behavior, and interrupted flows have been tested.
- Accessibility and UX: labels, focus order, text scaling, contrast, touch targets, loading states, empty states, and error messages work across supported screen sizes.
Inputs and assumptions
Your estimate is only useful when its assumptions are explicit. Record the following inputs before scoring the candidate:
- Supported platforms: list the Android and iOS versions, device classes, and form factors you intend to support.
- Build model: note whether the project uses Expo managed workflows, a prebuild or development build, React Native CLI, or a combination of Expo and custom native code.
- Release environments: identify development, staging, beta, and production API endpoints, feature flags, analytics destinations, and authentication clients.
- Critical journeys: define the actions that must work, such as sign-in, account recovery, checkout, data synchronization, push notification routing, or content creation.
- Data sensitivity: identify personal, financial, health, location, or credential-related data and document where it is stored, transmitted, and logged.
- Native dependencies: list libraries that require permissions, platform configuration, custom build plugins, native modules, or manual setup.
- Operational ownership: assign owners for build failures, crash investigation, store communication, certificate renewal, and post-release monitoring.
Use a release candidate built with production-like settings. A development build can hide issues involving minification, permissions, signing, network security, environment variables, native initialization, or asset loading. Verify that the app can start from a clean install, upgrade from the previous version, and recover after a terminated or interrupted session.
Do not treat a passing automated suite as a substitute for manual device checks. Automated tests are valuable for repeatability, while hands-on testing catches visual, permission, keyboard, notification, and lifecycle problems that may not be represented in the test environment.
Worked examples
Suppose a team defines 30 applicable checks. Twenty-two are complete, four are in progress, and four are blocked. Using the values above, the score is 24 out of 30, or 80 percent. That sounds reasonable until the team examines the blocked items: production signing, authentication expiry, crash reporting, and a broken purchase restoration flow. Because these are release gates or high-impact journeys, the candidate is not ready. The next action is not to improve the percentage generally; it is to resolve and retest those specific blockers.
Consider a second candidate with 26 applicable checks: 24 complete, one in progress, and one blocked. The score is 24.5 out of 26, or approximately 94 percent. If the blocked item is a nonessential visual refinement and the in-progress item is documented accessibility follow-up, the team may choose a controlled release. That decision should include an owner, a target date, and a monitoring plan rather than an assumption that the work no longer matters.
For platform review, make the evidence separate where needed. An Android build may pass while the iOS build fails because of a permission declaration, native dependency configuration, signing issue, or notification setup. Record Android and iOS build status independently, then test the shared JavaScript flows on both platforms. If your app uses deep links, compare cold-start, background, and already-open navigation cases using the React Native deep linking guide.
Similarly, storage and offline behavior deserve their own checks. Confirm what the user sees when writes are queued, synchronization fails, data conflicts, or local data is cleared. The offline-first guide and React Native storage comparison can help structure those decisions.
When to recalculate
Recalculate readiness whenever the release candidate changes in a way that can affect runtime behavior, delivery, or compliance. That includes upgrading React Native or Expo, changing native modules, modifying authentication or payments, adding permissions, changing API contracts, altering storage or synchronization, replacing a navigation or UI library, and switching build or signing configuration.
Run the review again after fixing a production defect. A patch can resolve one issue while changing startup behavior, caching, navigation, or platform configuration. Rebuild both platforms when a shared dependency or native configuration changes, and retain the previous score so the team can see whether risk decreased or merely moved.
Before submission, perform these final actions:
- Build clean Android and iOS release artifacts from the intended commit.
- Install each artifact on a clean device or simulator and test the critical journeys.
- Test upgrade behavior from the currently distributed version.
- Verify permissions, notification routing, deep links, offline states, accessibility basics, and error recovery.
- Confirm version numbers, app identifiers, signing, icons, screenshots, descriptions, privacy information, and release notes.
- Confirm crash and event monitoring identifies the release correctly and that someone is responsible for reviewing it.
- Record unresolved risks, owners, mitigations, and the date of the next review.
Store this checklist beside your CI/CD configuration and release notes. Revisiting the same inputs after each meaningful change turns production readiness from a last-minute opinion into a repeatable part of React Native app development.
