Make the release build reproducible
At React Native handover, record the source of the artifact being reviewed: commit, dependency lock, React Native version, native toolchain and build number. A package from an unidentified local folder is not a reliable release reference. Verify that a clean environment can produce the build from the documented recipe. Never copy signing secrets into the review report.
Android and iOS have distinct outputs and signing processes. The official React Native iOS publishing guide covers release configuration and submission. Apply instructions appropriate to the project's version and tools. Repeat debug-build checks on the release package. Assign findings about missing resources, wrong application identifiers or inconsistent build numbers, and include the artifact identity with each result.
Separate environments and verify store-account access
When setting up the release process, explicitly map test and production API destinations, notification configuration and application identifiers. A package connected to a test server must not accompany store copy promising a live service. An existing installation or cache can conceal the wrong environment; test clean installation and upgrades from the current release separately. Do not embed privileged service credentials in the app.
Name the account owner, submission role and person responsible for billing or agreement acceptance. Use appropriate permissions instead of a shared personal login. Do not expect an unauthorized team member to accept store terms. If certificates, provisioning or account access are incomplete, store submission remains pending even when technical tests pass. Record environment evidence without exposing secrets: destination class, role and check date are enough for the review.
| Check | Evidence | Retest condition |
|---|---|---|
| Release package | Commit, application identifier, build number | After producing a new artifact |
| Production destination | Network destination used by the release build | After environment configuration changes |
| Account access | Verified authorized role | After team or certificate changes |
FROM READING TO A NEXT STEP
Review store release readiness
Share the current build, target stores and open test findings.
Test sessions and API failures through real tasks
API acceptance covers more than displaying a successful response. Define behavior for sign-in, sign-out, expired sessions, incorrect credentials and unauthorized record access. Check that returning from the background cannot display another account's stale data. A token-refresh failure should not silently produce an endless loading screen. Include the transitions, not only the final authenticated page.
In a controlled test environment, simulate weak connectivity, disconnection, server errors and timeouts. Retrying an action that creates data can create duplicates; the user needs a clear state and a deliberate retry decision. Keep passwords and personal information out of logs. Each finding needs the screen path, build, network condition and expected result. When API or session behavior changes, retest the same failure scenario instead of checking only the opening screen.
Match permissions and store disclosures to actual data flows
Within mobile application scope, review camera, location, microphone and notification permissions at the point of use. Explain which tasks remain possible when the user declines. Do not retain an unused permission merely because it might be useful later. Include third-party SDK collection in the inventory; saying the team does not collect data is insufficient to describe the behavior of the complete app.
Google Play's user-data policy addresses disclosures and SDK responsibilities. Apple requires apps supporting account creation to let users initiate account deletion within the app. Review current requirements against the actual product. Store privacy declarations, policy links and network behavior should agree. Deletion is distinct from signing out or temporarily suspending an account; the product owner must validate the intended scope.
Permission declined
Explain why the feature is unavailable and offer an alternative task when possible. Observe both initial refusal and permission removal later in device settings.
SDK review
Record data types, transmission purposes, destination services and disclosure ownership. An SDK update may require another review of store declarations.
Connect real-device tests and store copy to the same build
During mobile performance review, test startup, scrolling, keyboard behavior and image loading through actual tasks. Alongside simulator checks, run the release package on representative older and newer supported devices. Android back navigation, iOS safe areas, small displays, larger text and device permissions can behave differently. Keep untested combinations visible in the device matrix.
Screenshots and descriptions should reflect what the submitted version can do. Do not present an unreleased feature as available. Open support and privacy links outside the store console to verify access. Where reviewer access is needed, the authorized team prepares a suitable test account in the private store fields, not in the public report. Confirm crash reporting identifies the release version and that diagnostic events avoid unnecessary personal information.
Plan recovery around how stores distribute versions
The release and monitoring plan continues after submission. Assign ownership of review status, distributed versions, failure signals and support requests. Devices using an older client can remain active; an API change must not assume every user has already received the latest app. Document the compatibility range between client versions and server behavior for critical features.
Recovering a store app may not be as immediate as restoring a web asset. Include a corrective build, available distribution-stop options and safe server-side feature controls where appropriate. Assess reversibility of data changes separately. Give the post-release check a date, owner and stopping criteria. These preparations do not guarantee store approval or uninterrupted operation. They distinguish verified outcomes from remaining work and make the response to failure concrete.
Get the checklist and discuss your scope
Your email and phone are used for this request. This does not subscribe you to a newsletter.
BEFORE YOU DECIDE
Frequently asked questions
Are debug-build tests sufficient?
No. Release configuration can change service destinations, optimizations and signing. Test the artifact submitted to the store on real devices. If a new package is produced, evidence from the previous package does not automatically validate the new version.
What if testing every device is impossible?
Build a representative matrix from supported operating systems, device classes and critical features. Distinguish real-device findings from simulator findings. State untested conditions in the handover notes rather than claiming flawless behavior across all devices.
Is account deletion just signing out?
No. Signing out ends a session; accounts and associated data require separate treatment. Assess current Apple and Google rules against the actual account-creation flow. If some data must be retained, the product owner needs to review the reason and user explanation.
Who should submit the app?
A person with the authorized store role submits it, while the account owner handles necessary agreements and organizational decisions. The delivery team can prepare the technical package. Define responsibilities and access instead of distributing personal login credentials.
Can we instantly restore an older version after failure?
Do not assume an immediate reversal across all devices. Store distribution options, review and installed versions affect recovery. Plan a corrective build, stopping distribution and server compatibility in advance. Treat data changes as a separate recovery decision.
LET’S DEFINE THE SCOPE
Review store release readiness
Share the current build, target stores and open test findings.
Discuss release scope