Review teams and store policies care about accurate marketing. Screenshots that promise features you have not shipped, show competitor logos, or use misleading before/after claims create rejection risk and refund churn.
Run this checklist on every release — especially when you reuse an old creative set after a UI overhaul.
Technical checks
- App Store 6.7" portraits exported at 1290 × 2796 px (PNG recommended)
- Play Store phone screenshots at 1080 × 1920 px portrait
- Google Play feature graphic at 1024 × 500 px if you use one
- No upscaled blurry captures — start from high-resolution device screenshots
- File names organized by locale and slide index for faster uploads
Message and policy checks
- Slide headlines match visible UI on the same frame
- No guaranteed ranking or income claims unless substantiated
- Age-restricted content flagged appropriately in listing metadata
- Third-party trademarks removed unless you have rights
- Pricing and trial language matches current in-app purchase rules
Story and conversion checks
- Slide one states a user outcome, not internal feature jargon
- At least one slide shows the primary happy-path workflow
- Text readable at thumbnail size in search results
- Visual style consistent across all slides and locales
- Localized sets updated when you localize metadata
After screenshots: Android closed testing
Polished visuals get users to the install button; Google Play closed testing gets personal developer accounts toward production access. If you still need twelve opted-in testers for fourteen days, run that track in parallel on TestMyApps while screenshots are in review.
FAQ
Common questions
How often should I refresh screenshots?
Refresh when UI, core value prop, or brand identity changes materially — typically each major release or repositioning, not every patch version.
Can I A/B test screenshots in the stores?
Apple and Google offer product page experiments on eligible accounts. Export alternate sets at the same dimensions so variants differ in message, not aspect ratio.