← All posts

July 29, 2026 · 4 min read

App Store screenshot rules: why listings get rejected (and how to pass review first time)

The screenshot rules App Store review actually enforces, the mistakes that trigger most rejections, and how to pass review on the first try.

Screenshot rejections are almost never mysterious. App Store review enforces a short list of documented rules, and the same few mistakes cause most rejected uploads. Here they are, in the order they usually bite, with the fix for each.

Illustration: an App Store listing on an iPhone stamped REJECTED

Rule 1: Exact pixel dimensions, no exceptions

App Store Connect validates dimensions before a human ever sees your listing. A 6.9-inch iPhone screenshot must be exactly 1320 × 2868 (or 2868 × 1320 in landscape). An iPad 13-inch set must be exactly 2064 × 2752. Close doesn't count.

This is the most common failure because generic design tools default to their own canvas sizes. Export at the store's numbers, not your artboard's. The full table, covering every display class in portrait and landscape, lives in our App Store screenshot sizes reference. We keep it verified against Apple's current App Store Connect documentation.

Rule 2: JPEG or PNG, and absolutely no transparency

Apple accepts .png, .jpg and .jpeg only, and images cannot contain an alpha channel. This one is sneaky: a screenshot can look fully opaque and still carry an alpha channel from whatever tool exported it. App Store Connect refuses it anyway.

If you're getting a format error on an image that looks fine, flatten it onto a solid background and re-export. (QuickScreens exports store-ready files without alpha channels, so this class of rejection simply doesn't happen.)

Rule 3: Show the app actually being used

Apple's App Review Guideline 2.3.3 is explicit: screenshots should show the app in use, not just title art, a login page, or a splash screen. Marketing headlines and device frames around the capture are fine and standard practice. A screenshot set that never shows real UI is not.

The same guideline family (2.3, "Accurate Metadata") covers honesty. What you show must be what users get. Showing features you haven't shipped, or another app's UI, risks rejection and worse.

Rule 4: Don't reference other platforms

Guideline 2.3.10 says not to include names, icons or imagery of other mobile platforms in your App Store metadata. A screenshot that shows your Android app, an "Also on Google Play" badge, or a Pixel-framed capture in your Apple listing is a rejection waiting to happen.

If you ship on both stores, keep two screenshot sets: iPhone and iPad frames for the App Store, Android frames for Google Play. One QuickScreens project exports both. See the Google Play sizes reference for that side's rules.

Rule 5: Google Play has its own tripwires

Play review is more automated, but the store listing policy bans the same categories of dishonesty: graphics that misrepresent the app, unattributed rankings ("#1 app!" with no source), and testimonials without attribution. Two Play-specific gotchas:

  • Screenshots below 1080 px upload fine but quietly disqualify your listing from Google's promotional placements.
  • The 1024 × 500 feature graphic is required before your preview video will display.

The pre-upload checklist

  1. Dimensions exactly match a supported size class (6.9″: 1320 × 2868; 13″ iPad: 2064 × 2752).
  2. No alpha channel. Flattened JPEG or PNG.
  3. Real app UI visible in every screenshot, not just artwork.
  4. No other-platform devices, names or badges in the Apple set.
  5. First three screenshots carry your pitch, because they're what shows in search results.
  6. Play set at 1080 px+, plus the 1024 × 500 feature graphic.

Frequently asked questions

Can I use device frames and marketing text in App Store screenshots? Yes. Framing your capture in a device mockup with a headline is standard practice and fully compliant, as long as genuine app UI is visible and the claims are accurate.

Why does App Store Connect say my screenshot is the wrong size when it looks right? Either the pixel dimensions are off by a few pixels (scaled exports are the usual culprit) or the file carries an alpha channel. Check both, then re-export at the exact store size.

Do rejected screenshots reject the whole app? A metadata rejection stops the release until you fix the listing. It's usually resolved by re-uploading corrected screenshots, with no code resubmission needed.


The fastest way to stay inside all of these rules is to never hand-manage dimensions at all. Open the editor, drop in your captures, and export sets that are store-exact by construction.