Many projects do not get blocked because the team cannot click submit. They get blocked because materials are incomplete, the materials do not match real app behavior, or reviewers cannot reproduce the intended path. This page organizes the required materials in the same order clients usually prepare them.
If you only want the minimum checklist, most teams need these categories first: build, app name and copy, icon and screenshots, privacy policy URL, contact email, and valid test credentials. If the app includes subscriptions, login, permissions, account deletion, geo restrictions, or special features, reviewer-ready explanations also need to be prepared.
Confirm which build is being submitted, which environment it points to, whether login is required, and whether access depends on a specific region or whitelist. Many teams technically provide a build, but it turns out to be an outdated or testing build that no longer matches the listing.
This includes the app name, short description, long description, icon, screenshots, and promotional copy. The common issue is not missing text, but overpromising, screenshots that no longer match production, or store copy describing features that do not exist in the actual app.
For both Google Play and the App Store, the privacy policy URL needs to be reachable and aligned with actual behavior inside the app. If the app collects phone number, location, device identifiers, or payment-related information, those points need to be reflected consistently in both the store declarations and the privacy policy.
If the app requires login, subscription, membership, OTP, invitation codes, or enterprise whitelisting, do not stop at sending one account. Reviewers need the shortest path to the core feature, not a guessing exercise.
If the app requests camera, photo library, microphone, location, or notification access, it helps to explain where the request is triggered, why it is needed, and what function is completed after approval. Permission purpose that does not match the real trigger page is a frequent review loop issue.
Apps with subscriptions should prepare subscription logic, price explanation, and restore-purchase behavior. Apps with account systems should prepare the account deletion entry and flow description. These are often no longer optional details; they are direct review checkpoints.
If the app has special entry points, region switching, or a prerequisite action before the core feature becomes visible, write that directly into reviewer notes. In practice, the more specific the note, the easier it is for reviewers to complete validation.
For example, the privacy policy says no data is collected while the app includes login and device identification, or the store screenshots still reflect an old version.
Invalid accounts, missing OTP delivery, deep subscription entry points, or unmentioned geo restrictions can all block validation.
The product team knows how to reach a feature, but reviewers do not. Reviewer notes should explain the path step by step: what to open first, where to tap next, and what should appear.
Finance, social features, UGC, AI generation, location services, VPN, or external payment redirection all require clear compliance boundaries and validation context. Without that, review naturally slows down.
Decide whether the submission is for Google Play, the App Store, or both, then confirm which build is actually ready for review.
Gather the name, descriptions, screenshots, privacy policy, and contact details early instead of assembling them on submission day.
Use test credentials from start to finish and verify login, subscription, permissions, account deletion, core entry points, and critical screens through the shortest path.