
A store listing makes promises about what an app does. Before release, check that those promises match the build a person can actually install. This checklist focuses on a pre-release review; our separate app store optimisation guide covers ongoing discovery and measurement.
Identify the build and audience
Record the version under review, supported devices, intended users and the main task. Keep a copy of the listing text and assets associated with that build. Otherwise, a reviewer may approve screenshots from one version and a description from another.
List the features that require an account, a subscription, a purchase or a connection. A person should not have to install the app to discover a material restriction that the listing could have explained clearly.
Check the title and description
Use a recognisable name and a concise explanation of the app’s purpose. Remove unsupported superlatives, repetitive keyword strings and comparisons you cannot substantiate. Check current store rules for field limits and permitted content rather than relying on a generic ASO checklist.
Read the description as a first-time user. Can you identify the main task, what you need to start, and whether important features cost extra? Replace vague claims such as “revolutionary productivity” with a concrete action the app supports.
Make screenshots truthful and readable
Capture screens from the relevant build using non-sensitive sample data. Explain the task shown without implying that a mockup is a feature already available. Check captions at the size users will see on a phone.
Show a coherent progression through useful tasks rather than several nearly identical screens. Verify that no real customer names, private messages, account numbers or credentials appear. Keep labels and interface language consistent with the locale being reviewed.
Apple’s product-page guidance describes the role of screenshots, previews and other listing assets. Use it alongside the specific submission requirements for your target store. Requirements differ between stores and can change.
Review pricing and access expectations
Check that descriptions of free features, trials and paid access match the app’s current purchase flow. Test what an unauthenticated or unpaid user can actually do. A screenshot of a premium function should not leave the impression that every installation includes it.
A listing review is also an opportunity to find broken support links or unclear account requirements. Open the support and privacy URLs as a visitor and ensure they refer to the correct app and operator.
Compare disclosures with app behaviour
Inventory the data the app and its included services handle. Compare that inventory with the store’s required privacy or data-safety answers and the app’s published privacy information. Investigate discrepancies rather than copying another developer’s declarations.
Check permissions in context: why is a permission requested, what happens if it is refused, and does the listing suggest functionality the app cannot provide? Have the responsible technical owner review details that a copywriter cannot verify.
Check each language and device presentation
Review translations with someone who understands the language and the app. Look for truncated captions, inconsistent feature names and support pages available only in a different language.
Where the app supports multiple device types, make sure the assets represent the right interface. A phone screenshot is not evidence that a tablet layout works. Keep accessibility checks for the app itself separate from the store asset review.
Prepare a review record
For each issue, record the field or asset, the reason it needs changing, the owner and the status. Confirm that the final text and screenshots correspond to the release build. Save the approved version so a later update has a clear baseline.
After release, review actual user feedback and acquisition results before optimising. Apple and Google provide their own product-page testing tools with specific eligibility and measurement rules. Running an experiment is a later optimisation step; it does not replace an accurate listing before launch.
Completion means the listing describes the real product, the required disclosures have been checked, and people can reach support. It does not mean a particular ranking or download increase is guaranteed.
Sources and further reading
Apple Developer: Creating your product page
Google Play: Store listing experiments
Related guides: Ongoing app store optimisation · Digital workflow skills.
Written and prepared by Kshitij Gupta.



