Is your mobile app ready for production?
A checklist for code, data, tests, release and responsibility for a React Native or Expo app.
Assess production readiness using evidence of app behaviour. Scope the review around features, data, dependencies and risks, regardless of who or what helped create the code.
Secrets, sessions and access
Confirm that secrets and private credentials are absent from the repository and app bundle. Public client configuration is not a secret; check its permissions and restrictions separately.
Check token expiry and permissions. Map ownership of the repository, environments, backend and store accounts.
- Separate development, staging and production configuration.
- Test logout, session expiry and network loss.
- Identify unused credentials and technical accounts. Revoking them requires a separately authorised procedure and dependency checks.
Dependencies and architecture
Check dependency versions, library maintenance, module boundaries, and consistency of data and error handling, regardless of how the code was written.
Data flows and failure paths
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, performance and crashes
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.
Monitoring and observability
Before release, decide who sees crashes, API errors and degradation and who responds.
Check what enters the logs, who can access it and how long it is retained. Do not log secrets or data unnecessary for diagnosis.
Signing, stores and rollback
A production build should come from a documented process rather than one laptop. Verify certificates, store accounts, privacy labels and the release plan.
Define how to stop the rollout or ship a corrected version, taking account of store constraints and the update method.
- Reproduce the build in a clean environment.
- Release to internal testers.
- Monitor a phased rollout.
- Document response and support procedures.
When an independent review helps
An independent review is useful before launch, code handover, investment or major modernisation. It should separate release blockers from improvements, attach evidence and finish with an action plan rather than a loose list of comments.
Which decision should the review support?
Do not choose a rewrite solely because a previous supplier or an AI tool created the app. Record the problem, evidence and alternatives.
If your team already has sufficient evidence, another audit may not be the next step. Building a new app starts with user needs and product scope, not an audit of code that does not exist.
- Release the app. Check: reproducible build, critical journeys, known blockers and responsibility for incident response. Decision inputs: test results for the agreed platforms and environments, accepted risks, a decision owner, and a release and incident-response plan.
- Remediate first. Check: impact on users or data and dependencies between fixes. Decision inputs: an ordered remediation plan and a recheck scenario.
- Take over development. Check: access to code, accounts and environments; build reproducibility; account ownership and release authority; maintenance responsibilities. Decision inputs: access gaps, run instructions and an agreed handover scope. Taking over development does not automatically transfer an app between store accounts or migrate services.
- Rebuild a selected module. Check: why remediation is insufficient; module boundaries, dependencies and change risks. Decision inputs: a comparison of repair and rebuild options with acceptance criteria.
Definition of Ready before review
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.
Evidence, priorities and recheck
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.
Scope a review before release or handover
Describe the app, the decision you need to make and the evidence available. The conversation establishes fit and scope; it does not deliver the audit or guarantee store approval.
For development or stabilisation, see our mobile app service.
Frequently asked questions
- Does an AI-built app need a different audit?
- An app does not need a separate readiness standard solely because AI helped build it. We scope the review around its features, data, dependencies and risks.
- Does this checklist replace a security audit?
- No. It is a production-readiness review, not a pentest, certification or legal opinion.
- Does the audit include fixing the code?
- The standard audit ends with findings and an action plan. Remediation and retesting require a separately agreed scope.
- Do we need to rewrite the entire app before a handover?
- Do not assume that in advance. A review should identify problems, their impact and the available options: remediation, takeover or rebuilding a selected part. The decision depends on evidence and the agreed scope.
Content updated: October 12, 2026
Google Preferred Sources
See GMI more often in Google
Add gmi.software as a preferred source. Google may highlight our new articles more often in Top Stories and supported AI experiences.