Treat “ready to submit,” “sent for review,” “accepted,” and “available to users” as different states. Keep the selected build, listing answers, access needed for review and the person responsible for the next step in one release record.
Start with the build you intend to ship
Pick the exact version and build you plan to submit, then test that build on supported devices. Recheck the main journey from a fresh install or the agreed starting state: sign in if required, complete the core task, save or retrieve the result, and exercise important error and empty states. Verify that linked services are available to reviewers and that any purchases or account-based features can be examined using the access you provide.
Apple’s App Review Guidelines call for complete, tested submissions with accurate information and access to account-based functionality. Google Play’s prepare-for-review guidance directs developers to provide the app-content information needed for policy and legal checks. Read the current instructions for your own app and market; this checklist does not replace either platform’s requirements.
- Finish the productTest the submitted build and its important paths
- Complete the recordAccurate listing, privacy and review information
- Submit the selected buildUse the platform’s review workflow
- Respond to the outcomeTrack status and resolve specific questions
Write down what is actually in this build, what remains unavailable, and how a reviewer reaches the relevant feature. Remove placeholder text, broken destinations and test-only controls that do not belong in the submitted version. If a feature depends on hardware, location, a server or a demo account, make the setup requirement explicit and verify it before submission.
Complete the store page and reviewer instructions
| Check | What to verify before submitting | Evidence for your release record |
|---|---|---|
| App identity and build | The selected build belongs to the intended app record and version; bundle/package identity and version details match the release plan. | Platform, app identifier, version/build number and selected artifact. |
| Listing and destinations | Names, descriptions, screenshots, support contact and website links describe the current app and open correctly. | A review of the final listing and tested public URLs. |
| Review access | A reviewer can reach account-based or restricted areas using the platform’s requested instructions and safe demo access. | A tested demo route or a clear explanation of access limits; never a real customer account. |
| Privacy and data answers | Store disclosures match the app, SDKs, permissions and linked privacy information for the actual build. | A feature-to-data inventory and the person who verified each answer. |
| Content and policy forms | Age/content, regulated capabilities, declarations and other console questions are complete and consistent with the product. | The submitted answers and any supporting material the console requests. |
| Release responsibility | The authorized account holder knows who submits, checks messages, fixes issues and chooses availability settings. | Named owner, notification route and next check date. |
Apple’s submission instructions require the version’s information and build to be in place, then use separate “Add for Review” and “Submit for Review” actions. Reaching a ready state is not the same as sending the submission. Check the status in App Store Connect after the authorized person completes the final action.
For Google Play, complete the current items shown on the app’s App content page. Its required declarations depend on the product and the policies that apply. For example, Google says apps that access sensitive permissions or data under its User Data policy must link a privacy policy on the store listing and within the app. Confirm the exact current requirement for your case instead of copying another app’s answers.
Make privacy answers match the shipped behavior
Review the data flow in the release build, not only the code you wrote. List data collected or transmitted by the app and included SDKs, why each item is used, whether it is linked to an account, and how it is retained or deleted. Check permission prompts against the feature that uses them. Compare those observations with the privacy policy and each store’s current disclosure questions.
Apple says developers are responsible for third-party SDKs as well as their own app behavior in its review guidelines. Google Play’s preparation page connects app-content declarations with its policies and legal requirements. A privacy-policy URL alone does not prove that every console answer is accurate. Assign a person to verify each answer against the actual app and SDK configuration.
If people can create accounts, check the current account-deletion obligations for each platform and make sure the described route works. Do not submit a placeholder, dead URL or a promise for a feature that is not in the build. Privacy, deletion and permission details should be tested as user journeys, not treated as copy-only chores.
Prepare a reviewer path that does not depend on guesswork
For a fictional meal-planning app with a sign-in screen, the reviewer instructions could say which demo credentials to use, how to open the sample plan, and which screen demonstrates the feature under review. The account must be safe for review, active for the relevant period and free of real personal data. If the app can be explored without an account, say how to reach the feature from a clean launch instead.
Apple’s complete-review information guide asks developers to supply what App Review needs to examine the app, including access details and any required hardware. Make instructions concise and verify them against the submitted build. A reviewer should not have to infer a sequence from marketing screenshots.
Do not include real user passwords, production access tokens or private signing material in review notes. Use the platform’s designated fields and safe demo setup. If a limitation is security-related, explain the supported test route and contact the platform through its official process rather than exposing a secret.
Submit, monitor, and respond without promising a date
Before the final submission action, check that the selected build is still the intended one and that all required information is saved. Record the date, build, platform status and responsible account owner. After submission, monitor that console for questions or status changes and respond through its stated process. If the platform identifies an issue, reproduce it on the named build, compare it with the cited requirement, and prepare a corrected build or clarification as appropriate.
Do not advertise a fixed review duration based on one previous release or assume that “submitted” means “approved.” Apple’s documented statuses distinguish waiting, review and other outcomes; Google Play likewise shows review and publishing state in Play Console. Current queues and app-specific questions can differ. Tell teammates what the console says and when it was last checked, rather than turning an estimate into a promised launch date.
Once accepted, verify the availability setting and the public listing separately. Some release controls can make an accepted build available later or to a limited audience. A store approval is not evidence that every intended user can already download it in every market.
Turn the checklist into a team release handoff
Keep one release note with the app/version, build identifier, listing revision, privacy review owner, reviewer-access method, submission state, open questions and next responsible person. Store credentials in the account owner’s approved password or access-management process—not in the release note or source repository. Use delegated roles instead of sharing an account password when the platform supports them.
For a new project, agree who prepares store information, who owns the developer accounts, who responds to review questions and whether the delivery ends at a test build, submission or release. The mobile app MVP checklist helps define first-release scope; the handover checklist covers maintainable source and release access. Moocsoft offers Flutter mobile app development; bring the target platforms and release responsibilities to a project discussion.
Common questions
Does a submission checklist guarantee app approval?
No. It helps find missing or inconsistent items before submission. The platform applies its current requirements to the specific app and may request changes or information.
How long does App Store or Google Play review take?
There is no review date promised by this checklist. Timing can vary by platform, submission and any questions raised. Check the current status in the relevant console and avoid treating an estimate as a launch commitment.
Is “Ready for Review” the same as submitted to Apple?
No. App Store Connect documents a separate final “Submit for Review” action after preparing a submission. Check the status after the authorized account holder completes it.
What should I give a reviewer if my app requires an account?
Provide the review access and concise steps requested by the platform, using a safe, active demo account or demo mode where appropriate. Do not expose a real customer account, password in public notes or production secrets.
Do Apple and Google use the same submission forms?
No. Each console has its own workflow, metadata and declarations. Complete the current requirements separately for each platform and supported app version.
References and further reading
Published by Moocsoft, an independent Flutter development studio. Examples and worksheets are illustrative. Project scope, platform requirements and release responsibilities need to be agreed for each project.