Five checks before submitting an app for review

First, test the build being submitted

Test the actual submission build from installation through sign-in, a principal task and recovery from an error. Record the device and environment, and check that development-only endpoints or settings are absent.

Pair each procedure with an expected result. “Create a booking and find it in the list” is more reproducible than “check bookings.” Document any external hardware or setup required.

Apple’s pre-submission guidance includes checking crashes, providing complete app information and keeping services accessible. Recheck the current store guidance for each submission.

Second and third, align access and listing details

Second, make the app reviewable. Prepare working access and reproducible steps for restricted features. Explain any additional authentication or required data. Follow the instructions from a fresh environment before submitting.

Third, align the listing with the build. Descriptions, screenshots and support links should reflect what is actually available. Explain access conditions rather than presenting restricted or unfinished functionality as generally available.

Google Play review preparation covers app access and submission information. Keep the account setup, steps, required data and verification date together in the project checklist.

Fourth and fifth, review data and purchase flows

Fourth, reconcile data handling and disclosures. Include SDK behavior when reviewing permission explanations and submitted information. Test the experience when a user declines permission.

Fifth, check the product and purchase flow. Payment choices depend on the product, region and distribution conditions. Exercise cancellation, restoration and delayed outcomes as well as success.

Check the applicable details in the Apple review guidelines and the current policies of the relevant store. These five topics are an organizational checklist, not a promise of approval or a ranking of rejection causes.

Track review responses against the submitted version

When a reviewer requests changes, record the version, reproduction steps, observed result and planned response. Distinguish a defect requiring a new build from missing instructions.

Respond with steps and screens that let the reviewer verify the correction. If submitting another build, state what changed. The aim is evidence that addresses the request rather than repeated assurances.

Keep submission and desired launch dates separate. Assign an owner for review preparation and incoming questions, and plan for possible corrections and another review. These operational records help the team continue work after development is nominally complete.