Apple reviewed 9,100,620 app submissions in 2025 and rejected 2,093,244 of them — a 23.0% rejection rate, according to the company's 2025 App Store Transparency Report. Its App Review guidance also names "inaccurate screenshots" as a common issue that sends submissions back.

For a design team, that failure mode is expensive. A screenshot rejection typically lands 24 to 48 hours after submission, costs a full review cycle, and can cost a launch if you are working against a date or a paid campaign. Unlike a crash, it is entirely preventable: the rules are published, specific, and testable before upload.

Here is what the review data shows, the screenshot rule that causes the most avoidable rejections, and a pre-flight checklist for both stores.

What 9.1 million submissions reveal about rejections

Apple's transparency report is the closest thing the industry has to a census of App Review. In 2025 it counted 2,172,472 live apps and 9,100,620 submissions reviewed — a figure that includes updates, not just new apps.

Guideline sectionSubmissions rejectedShare of all rejections
Performance1,354,41864.7%
Legal495,67323.7%
Design415,53219.9%
Business283,82013.6%
Safety151,1597.2%
Other4,1450.2%

The shares exceed 100% because a submission can be rejected against more than one guideline, as Apple notes in the report's footnotes.

Two numbers matter for screenshot work. Performance accounts for 1,354,418 rejections, or 64.7% of the total — and that section contains guideline 2.3, Accurate Metadata, which governs screenshots, previews, descriptions, and keywords. Performance also covers crashes and completeness, so not all 1.35 million are metadata. But it is where screenshot issues live, and it is by far the largest bucket.

Second, 387,087 submissions were approved after an initial rejection — 18.5% of everything rejected. Rejection is usually a delay, not a verdict. The question is how many days you want to spend in the loop.

Apple's App Review page adds context the report cannot. It states that "on average, over 40% of unresolved issues are related to guideline 2.1: App Completeness," and it lists "Inaccurate screenshots" as a distinct common issue. It also publishes timing: at least 50% of submissions are reviewed in under 24 hours, 90% in under 48. A rejected set therefore costs one to two days per attempt before you count re-export and re-upload.

The store is also actively pruning. Apple removed 166,899 apps in 2025, including 72,271 under Guideline 4.0 (Design) during cleanup for outdated apps. Stale metadata is not a neutral state.

The rule most designers miss: Apple's "majority in use" test

Most screenshot rejection stories trace to one sentence in Guideline 2.3.3:

Screenshots should show the app in use, and not merely the title art, login page, or splash screen. They may also include text and image overlays (for example, to demonstrate input mechanisms, such as an animated touch point or Apple Pencil) and show extended functionality on device, such as Touch Bar.

The operational detail lives in Apple's guideline reference for 2.3.3, and it is stricter than most marketing teams expect:

  • More than half of the screenshots for each device type must show the app in use. App Review approves only submissions where the majority meet that test.
  • The count is concrete: with three screenshots per device, two must show the app in use; with four, three must.
  • One screenshot is sufficient for a device type, provided it shows the app in use.
  • The test applies per device type and per localization — a compliant English set does not rescue a non-compliant Japanese one.

Overlays are allowed, including touch indicators and Apple Pencil demonstrations, "as long as the primary app functionality in the screenshot isn't obscured." What fails is the inverse: an app shown as a small mockup behind large promotional text, or a set built from a login screen and a splash screen. Apple's own example contrasts a surf app showing its dashboard and forecast against exactly that.

This is where polished agency creative often fails. A five-frame set with the phone at 30% scale, a gradient background, and a headline filling the frame can look premium in Figma and still fail the majority test, because the interface is decoration rather than subject.

Four adjacent rules belong in the same pass:

  • 2.3.2: screenshots and previews must indicate when featured items, levels, or subscriptions require additional payment.
  • 2.3.7: no prices or pricing terms in screenshots or previews.
  • 2.3.8: icons, screenshots, and previews must suit a 4+ audience even when the app is rated higher.
  • 2.3.9: you must hold rights to every asset, and account data shown should be fictional.

Six screenshot patterns that trigger rejections

1. The all-marketing set. Every frame is a headline plus a floating device with no readable interface. Fix it by allocating before you design: in a five-frame set, three frames show real UI at readable scale; two can carry benefit-led marketing.

2. The stale set. Screenshots from two releases ago, showing navigation the current build no longer has. 2.3.3 asks developers to update screenshots with each new version so they match the current UI. This is common because screenshots are the most-refreshed metadata element on both stores: AppTweak's 2026 benchmark found 54% of top U.S. App Store apps and 46% of top Google Play apps updated screenshots twice or more in 2025. Tie screenshot review to the release checklist, not the marketing calendar.

3. Price, promotion, and award copy. "50% off," "$4.99/month," "#1 app," "Editor's Choice," or a copied store badge. Apple's 2.3.7 prohibits prices and terms; Google's Metadata policy names "App of the year," "#1," "Best of Play 20XX," award icons, and discount claims as common violations. Replace claims with capabilities: "50% off" becomes "Unlimited exports."

4. Undisclosed in-app purchases. A premium feature or paywall shot with no indication of payment. 2.3.2 requires disclosure in the screenshot or preview itself — a line in the description does not cover it. Label the frame ("Pro — subscription required") or include the paywall.

5. Age-rating mismatch. Graphic violence, a weapon aimed at a character, or suggestive imagery in a mature app's set. 2.3.8 requires 4+ suitability regardless of the app's rating, and Google separately prohibits suggestive content and graphic violence in listing imagery. Choose frames that show mechanics rather than gore.

6. Borrowed assets and real data. A recognizable character, brand logo, celebrity photo, or a real customer's inbox or health dashboard. 2.3.9 makes you responsible for rights and asks for fictional account data; Google flags third-party trademarked characters and logos without permission. Use licensed or original art and synthetic data, and keep a rights log.

Google Play's formatting traps

Google's accuracy rules overlap with Apple's, but its formatting guidance catches teams that only read 2.3.3:

  • No ALL CAPS in the title, icon, or developer name unless it is part of the brand; no emojis or repeated special characters.
  • No unattributed testimonials, competitor comparison tables, or data comparisons in the listing.
  • No ranking or award claims in screenshots — Google names "Best," "#1," "Top," "New," "Discount," "Sale," and "Million Downloads."
  • No calls to action such as "Download now" or "Try now."
  • Taglines under 20% of the image, with UI prioritized in the first three screenshots and a clean status bar before capture.
  • No device frames on Wear OS, where screenshots must be UI only, 1:1, and at least 384 × 384 px.

By the numbers

  • 9,100,620 submissions reviewed by Apple in 2025; 2,093,244 rejected — 23.0%.
  • 1,354,418 rejections fell under Performance (64.7%), the section containing guideline 2.3.
  • 387,087 submissions were approved after rejection — 18.5% of all rejections.
  • 166,899 apps removed from the App Store, including 72,271 for outdated design (Guideline 4.0).
  • Over 40% of unresolved review issues relate to guideline 2.1; "inaccurate screenshots" is a named common issue.
  • 50% of submissions reviewed in under 24 hours; 90% in under 48.
  • 54% of top App Store apps and 46% of top Play apps updated screenshots twice or more in 2025 (AppTweak).
  • 1.75 million policy-violating apps blocked from Google Play in 2025; 80,000+ developer accounts banned (Google Security Blog).
  • +32% install-button clicks after a screenshot redesign and +36% conversion uplift from localized screenshots (ZiMAD, via SplitMetrics); +20% from screenshot A/B tests (Prisma, via SplitMetrics).
  • 58.7% vs 55.5% tap-to-install conversion, custom product pages versus default (AppTweak, 2025).

A 12-point pre-submission checklist

Apple

  1. More than half the screenshots for every supported device type show the app in use — 2 of 3, 3 of 4, and so on.
  2. Each device type has its own set; no iPad listing running an iPhone-only set.
  3. The UI matches the build you are submitting — no removed tabs, old paywalls, or outdated typography.
  4. No price, discount, ranking, award, or store-badge text; any paid feature is labeled as requiring purchase.
  5. All imagery is appropriate for a 4+ audience, even if the app is rated higher.
  6. Every asset is licensed or original, and any account data shown is fictional.

Google Play

  1. At least two screenshots, JPEG or 24-bit PNG without alpha, minimum dimension 320 px, maximum 3,840 px, long edge no more than twice the short edge.
  2. No ALL CAPS, emojis, or special-character padding in the title, icon, or developer name; no ranking claims, testimonials, comparisons, or CTAs.
  3. Taglines occupy less than 20% of each image, the first three screenshots prioritize real UI, and the status bar is clean.
  4. Form-factor listings meet their own rules — Wear OS is UI only, no frames, 1:1, at least 384 px.

Both

  1. Every localization is reviewed on its own; translated copy is not clipped, overflowing, or left in English.
  2. Alt text is added to each Play asset (140 characters or fewer), and screenshots are exported at store-ready sizes rather than resized afterward.

If your screenshots are rejected, the fastest path back

  1. Read the cited guideline before touching the artwork. A 2.3.3 rejection is about showing the app; a 2.3.7 rejection is about pricing copy. Fixing the wrong one buys another review cycle.
  2. Reply in the Resolution Center with what changed. Name the guideline and the frames you replaced. Reviewers look for evidence the issue is resolved, not for intent.
  3. Do not resubmit identical assets. Apple states that repeated violations of the same guideline make review take longer. A cosmetic reorder will not clear a majority-test failure.
  4. Appeal only when the rule was misapplied. If your set genuinely shows the app in use, use the App Review Board appeal rather than resubmitting. Expedited review exists for critical timing and should not be routine.
  5. For live apps, ask about a bug-fix submission. Apple does not delay bug fixes over guideline violations except for legal or safety issues, so a metadata fix blocking a critical release may qualify.
  6. Keep the source file, not just the export. A team that can re-export in 30 minutes treats rejection as a minor delay; a team rebuilding frames in Photoshop treats it as a week.

Compliance is the floor — conversion is the point

Meeting the rules keeps you on the store; it does not make the listing convert. The same research documents both risk and upside.

ZiMAD's screenshot redesign — a storyteller character on each frame, shorter action-led captions, and a mix of art overlays with real gameplay — produced 32% more install-button clicks in SplitMetrics testing, and its localized set lifted conversion in Japan by 36%. Prisma reported a 20% conversion boost from screenshot tests. AppTweak found custom product pages converting taps to installs at 58.7% versus 55.5% on default pages, yet 61% of apps and 74% of games ran none in 2025.

The translation: keep the majority of frames honest and readable, then spend creative ambition on the one or two frames carrying the value proposition. Test one variable at a time — first frame, caption, background, order — because a redesign that changes five things cannot tell you which one worked.

Localization is the same story. Apple assesses the majority test per localization, and Google asks for localized taglines even when in-game UI stays in its original language. A 35-locale export is only an asset if each locale's captions fit, read naturally, and leave the UI visible. ScreenCraft's locale templates and device-frame presets are built for that workflow: design the compliant set once, then export per locale and per device at store-ready dimensions instead of resizing after the fact.

FAQ

How many screenshots must show the app in use? More than half per device type. With three screenshots, two must show the app in use; with four, three must. One screenshot is acceptable if it shows the app in use.

Can screenshots include marketing text? Yes, as long as the majority show the app in use and overlays do not obscure the primary functionality. The failure case is a frame where the app appears only as a small mockup behind large promotional copy.

Do Apple and Google Play use the same rules? No. Google requires at least two screenshots, allows up to eight per device type, and sets a 320–3,840 px range with a 2:1 maximum aspect ratio. Apple's majority-in-use test has no direct Google equivalent, and Google adds formatting rules on capitalization, emojis, and ranking claims.

Sources