Is your mobile app ready for production?

Confirm that secrets are absent from the repository and app bundle, tokens expire correctly and permissions are minimal. Map ownership of the repository, environments, backend and store accounts.

• Separate development, staging and production configuration.
• Test logout, session expiry and network loss.
• Remove unused keys and technical accounts.

Lock dependency versions, review abandoned libraries and inspect module boundaries. Rapidly generated code can be repetitive without sharing one data and error model.

Map data from the screen through the API to durable storage. For each critical step, test timeout, retry, duplication, offline behaviour and user feedback.

Tests should protect login, payment or the product’s primary transaction. Measure app start, critical-screen responsiveness and behaviour on lower-end devices, then verify crash reporting with a controlled failure.

Before release, decide who sees crashes, API errors and degradation and who responds. Logs must support diagnosis without storing personal data or secrets.

A production build should come from a documented process rather than one laptop. Verify certificates, store accounts, privacy labels, phased rollout and the ability to stop or replace a defective release.

1. Reproduce the build in a clean environment.
2. Release to internal testers.
3. Monitor a phased rollout.
4. Document response and support procedures.

A review should not begin by guessing which commit and environment are authoritative. The team identifies the repository, baseline commit, run instructions, expected environment, build access and critical business journeys. If the app cannot be reproduced, that is an audit finding, but the boundary of the attempt must be recorded.

Before work starts, name the decision the review must support: release, take over, remediate or rewrite a selected module. Without this, findings have no useful order. A critical issue is one that affects release, data security, stability of the primary journey or the ability of an accountable team to maintain the product.

Every material finding should include a code or configuration location, reproduction conditions, impact and recommendation. Priority without evidence can be opinion, while a screenshot without context does not support a decision. The remediation plan should identify task dependencies and the condition for rechecking each finding.

After changes, the team should not close an issue solely because a pull request changed the code. Repeat the scenario, build or measurement that exposed the risk. React Native release checklist can organise the separate publishing stage, but it does not replace evidence specific to the product and its infrastructure.