Screenshots and app previews
Four rules produce nearly every screenshot rejection, and one of them is invented.
Show the app. Screenshots should show the app in use, not title art, concept renders or pure marketing imagery. A caption over a real screen is normal and widely done. Replacing the screen with an illustration is not.
No other mobile platforms. Guideline 2.3.10. An Android device frame, three navigation buttons, a Material status bar — any of these, and it is the most common way cross-platform teams get caught, because the asset pipeline is shared.
No fabricated social proof. Representative sample data is expected. Invented ratings, made-up user counts and fake testimonials are a metadata accuracy problem, and in the US they run into the FTC rule on fake and AI-generated reviews.
Match the device. iPad screenshots must show the iPad layout, not a scaled iPhone screen.
The invented rule: that captions or device frames are disallowed. They are not, and the entire top of every category uses them.
What actually gets rejected
An Android frame. The single most common one for React Native teams. Check every screenshot at full size and look at the chrome, not the content. This costs thirty seconds and prevents a multi-day cycle.
A screenshot of something the app does not do. Showing a feature that is coming, or a paid feature presented as though it is included, is a metadata accuracy problem.
Fabricated numbers. "Join 40,000 users" over a screen, a five-star row, invented press logos. If you cannot substantiate it, it is not a design choice.
Placeholder content. Lorem ipsum in a screenshot, a name like "Test User 3", a debug banner.
iPad screenshots that are stretched iPhone screens. Visible immediately, and it suggests the iPad support is nominal.
What is fine, despite what people believe
- Captions over the screen. Universal in every top-grossing category.
- Device frames, as long as the device is an Apple one.
- Sample data, as long as it is representative rather than aspirational.
- Design continuity between screenshots — backgrounds, colour, a narrative order.
- Preview videos showing real app footage with captions.
The timing rule that catches people
Only promotional text changes without a submission. Name, subtitle, keywords, description, screenshots and preview videos all require a submission and review, even as a metadata-only submission.
The practical consequence: if you are already queued for a build, attach every metadata change you want to that submission. Discovering afterwards that a screenshot needed fixing means another full cycle for something that could have ridden along. What a rejection actually costs.
The check before you submit
# other-platform references in metadata and in-app strings
grep -rniE 'android|google play|play store|samsung|pixel' \
fastlane/metadata/ store/ src/ app/ 2>/dev/null | head
# unsubstantiated claims in listing copy
grep -rniE '[0-9,]+\+? (users|customers|downloads|reviews)|as seen (in|on)|#1 ' \
fastlane/metadata/ store/ 2>/dev/null | headThen look at every image at full size. The device chrome, the status bar, the content. That is the part a grep cannot do, and it is where the rejection lives.
Related
Guideline 2.3.10 in detail · What reviewers actually test · The first-submission checklist
shipcheck scans listing metadata and in-app strings for other-platform references and unsubstantiated claims. It cannot look at your images, and says so rather than implying otherwise. What it checks.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
Do App Store screenshots have to show the actual app?
Yes. Screenshots should show the app in use rather than being purely marketing images, title art or concept renders. Adding a caption over a real screen is normal and widely done; replacing the screen with an illustration is not.
Can screenshots show an Android device?
No. Guideline 2.3.10 covers references to other mobile platforms in your metadata, and a device frame with Android navigation buttons or a Material-style status bar is exactly that. It is the most common way cross-platform teams get caught, because the asset pipeline is shared.
Can I use fake data in screenshots?
Representative sample data is normal and expected. Fabricated social proof is not - invented ratings, made-up user counts, or fake testimonials in a screenshot are a metadata accuracy problem and, in the US, run into the FTC rule on fake reviews.
Do I need iPad screenshots?
Only if the app supports iPad. If it does, the iPad screenshots must show the iPad layout rather than a scaled iPhone screen, and an app claiming iPad support with no genuine iPad experience is a separate problem.
Can screenshots be changed without a new build?
No. Name, subtitle, keywords, description, screenshots and preview videos all require a submission and review, even as a metadata-only submission. Promotional text is the only field that changes freely.
shipcheck. “Screenshots and app previews.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/rejections/screenshots-and-app-previews/