App screenshots and previews App Review checklist
Screenshots and previews are not decorative. They are public claims App Review can compare against the submitted app.
Build an asset-to-screen map before uploading screenshots or app previews. Apple documents uploading app previews and screenshots, plus separate specifications for each asset type. AppReviewReady interpretation: every visual promise should be testable in the submitted build, storefront, and locale.
Map each asset to a real screen
List every screenshot caption, app preview scene, badge, metric, testimonial, device frame, and before-after comparison. Then identify the in-app screen, account state, region, and data state that proves it.
If an asset shows a paid feature, beta feature, regulated claim, or region-specific workflow, the reviewer should be able to reach that state with the submitted build.
Remove misleading visual shortcuts
- Do not show unavailable UI, fictional rankings, unsupported medical or financial outcomes, or fake platform integrations.
- Avoid using production customer data, private messages, real addresses, or third-party logos without rights.
- Check that charts, scores, and claims match the app's real calculations.
- Make subscription, purchase, and locked-feature states clear when they appear in assets.
- Keep screenshots synchronized with redesigned navigation before submitting an update.
Review each locale separately
Localized screenshots often drift from the actual app copy. Verify language, currency, dates, support promises, legal disclaimers, and feature availability per storefront.
AppReviewReady interpretation: a compliant English asset can become risky when localized copy promises a feature that is not available in that country or app version.
Check preview and screenshot specifications
- Confirm required device sizes, orientation, duration, file type, and resolution.
- Watch every app preview without sound and with sound where used.
- Verify the first seconds show real app value rather than a generic logo animation.
- Test dark mode and light mode if assets imply both.
- Freeze an asset version after final QA so marketing changes do not bypass review.
Asset proof map
Keep the map with the submission record. It turns App Store asset review from subjective opinion into a repeatable QA step.
After launch, compare assets with support questions and conversion events. If a screenshot attracts clicks but causes refund or confusion, revise the claim before the next update.
For apps with generated or personalized content, use owned sample data that represents the real feature without implying that every user will get the same output. This matters for AI, finance, fitness, education, and creator tools where screenshots can easily overpromise.
Review asset changes after pricing, entitlement, or country availability changes. A screenshot that was truthful in one storefront can become misleading after a feature is removed, paywalled, or restricted to fewer countries.
If an app preview depends on motion, sound, or timed interaction, watch it on a small screen. Text that is legible in the editing tool may be unreadable in the App Store listing.
Asset proof: Asset name: [screenshot/preview] Claim shown: [text or visual] In-app proof route: [steps] Required state: [account, purchase, region] Rights check: [owned/licensed] Localization check: [locale] Spec check: [size/duration]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check App Store assets
Audit screenshots, previews, claims, rights, and localization before submission.
Open the tool