App Store Submission Gate (QA)

App Store Submission Gate (QA)

1. 01

   Freeze the build and record the exact version hash before any store submission

   Tag the release in your project tracker and note which platform account (agency-owned or client-owned) holds the binary. A frozen hash prevents the classic failure where a client requests a copy change mid-review and the submitted build no longer matches what was approved internally.

2. 02

   Run the Apple and Google metadata audit against both stores' current rejection lists

   Check privacy nutrition labels, data-safety declarations, account-deletion path, and permission strings. Missing account deletion has been a recurring rejection cause since Apple began enforcing it; a 30-minute metadata pass before upload saves a 3 to 7 day review cycle.

3. 03

   Test the app on a physical device on a clean install, not a simulator or a warm build

   Push notifications, biometric login, and deep links behave differently on first launch. Have one person outside the build team install from TestFlight or the Play internal track and complete the primary client task end to end.

4. 04

   Confirm every third-party integration has a production credential, not a sandbox key

   Payment processors, CRMs, and analytics keys are the most common source of post-launch breakage. Map each integration to the account owner and verify the production key is live before the binary goes to review.

5. 05

   Verify the client's legal pages, support contact, and store listing assets are final

   Screenshots, app icon, description copy, and the privacy policy URL must match the shipped build. A policy URL pointing to a staging domain is a routine rejection trigger and an easy one to miss under delivery pressure.

6. 06

   Document the rollback path and the store account recovery owner

   Record who holds the Apple Developer and Google Play Console credentials, the two-factor recovery method, and how to pull a release if a defect surfaces in the first 72 hours. Agencies that skip this step discover the gap only when a client calls about a broken update.

7. 07

   Schedule the post-launch monitoring window and assign a named owner

   Set a 14-day watch period covering crash reports, review sentiment, and support tickets, with one person accountable for triage. Hand the monitoring checklist to the client at retainer handoff so the responsibility transfer is explicit.