App Store Rejections: 2026 Screenshot Compliance Guide

App Store screenshot rejections trace back to seven causes: screenshots that do not show the app in use (Guideline 2.3.3), wrong pixel dimensions, misleading or outdated UI, references to non-iOS platforms, localization mismatches, prohibited claims, and age-inappropriate content [1]. Apple rejected 2,093,244 of the 9,100,620 submissions it reviewed in 2025, roughly 23 percent [3].

This guide covers every screenshot-related rejection reason Apple and Google enforce in 2026, the exact guideline numbers behind each one, what Apple's own transparency data says about how often rejections actually happen, and the fixes that get your app approved on the first try.

TL;DR:

• The real rejection rate: Apple reviewed 9.1 million submissions in 2025 and rejected 2.09 million, about 23 percent [3]. The uncited "40 percent" figure most guides repeat does not match Apple's own report.
• Most-cited screenshot rules: 2.3.3 (must show the app in use, no splash screens), 2.3.10 (no Android or other-platform references), 2.3.8 (4+ age safe), 2.3.7 (no trademarks, prices, or unverifiable claims) [1].
• Dimensions are binary: the 6.9-inch iPhone class accepts exactly three portrait resolutions (1260x2736, 1290x2796, 1320x2868); anything else fails at upload, before a reviewer ever sees the build [2].
• Localized listings need localized screenshots: a translated description with English-only screenshots reads as inaccurate metadata under Guideline 2.3.
• Google Play differs: JPEG or 24-bit PNG with no alpha, each side between 320 and 3840 px, max dimension no more than twice the min, up to 8 screenshots per device type [4].
• Pre-flight: run the free ASO audit tool and validate dimensions with the device dimensions reference.

Table of Contents

• How Often Does Apple Actually Reject Submissions?
• Which Guidelines Govern Your Screenshots?
• Rejection #1: Screenshots Do Not Show the App in Use
• Rejection #2: Wrong Screenshot Dimensions
• Rejection #3: Misleading or Inaccurate Screenshots
• Rejection #4: Non-iOS Platform References
• Rejection #5: Localization Mismatch
• Rejection #6: Prohibited Claims in Screenshots
• Rejection #7: Age-Inappropriate Screenshot Content
• What Causes Google Play Screenshot Rejections?
• What Should You Check Before Every Submission?
• How Do You Stay Compliant Without Manual Checks?

How Often Does Apple Actually Reject Submissions?

Apple reviewed 9,100,620 App Store submissions in 2025 and rejected 2,093,244 of them, a rejection rate of roughly 23 percent, according to Apple's own 2025 App Store Transparency Report [3]. Apple does not publish a screenshot-specific count, but the guideline section that contains the screenshot rules (Performance, Section 2) was the most-cited section, at 1,354,418 rejections.

Many rejection guides repeat a "30 to 40 percent" or "40 percent" rejection rate with no source attached. Apple's transparency reports, published yearly since 2022, are the only primary data, and they put the aggregate rate lower. Here is the 2025 breakdown by guideline section [3]:

Two honest caveats. First, these counts sum to more than the 2.09 million total because a single rejection can cite several sections. Second, Performance covers more than metadata (app completeness, beta builds, hardware compatibility), so not all 1.35 million are screenshot problems. What the data does establish: the section your screenshots live under is the one reviewers cite most, so screenshot compliance is not a niche concern. It sits in the largest rejection bucket there is.

Which Guidelines Govern Your Screenshots?

Apple's App Store Review Guidelines Section 2.3 ("Accurate Metadata") contains the rules that cause most screenshot rejections [1]. Six sub-guidelines do almost all the work: 2.3.1 (no misleading marketing), 2.3.2 (disclose paid features), 2.3.3 (show the app in use), 2.3.7 (no trademarks or prices), 2.3.8 (4+ age appropriate), and 2.3.10 (no other-platform references).

Section 2.3 opens with the principle behind all of them: metadata, "including privacy information, your app description, screenshots, and previews," must "accurately reflect the app's core experience" and stay up to date with new versions [1]. In practice:

• Guideline 2.3.1: No hidden features, no misleading marketing. Screenshots must represent what the app actually does.
• Guideline 2.3.2: If your app includes in-app purchases, screenshots must clearly indicate which featured items or levels require additional payment.
• Guideline 2.3.3: Screenshots must show the app in use. Not splash screens. Not login pages. Not title art.
• Guideline 2.3.7: No trademarked terms, popular app names, or pricing information packed into metadata "just to game the system" [1].
• Guideline 2.3.8: All metadata (including screenshots) must be appropriate for a 4+ age rating, even if the app itself is rated higher.
• Guideline 2.3.10: No names, icons, or imagery of other mobile platforms or alternative app marketplaces in your screenshots.

These six guidelines account for the vast majority of screenshot-related rejections. Let's break down each rejection type, why it happens, and how to fix it.

Rejection #1: Screenshots Do Not Show the App in Use

Guideline: 2.3.3 [1]

The most common screenshot rejection for indie developers is a Guideline 2.3.3 violation: Apple's rule states that screenshots "should show the app in use, and not merely the title art, login page, or splash screen" [1]. The fix is to lead with real, captured app UI and treat marketing-only frames as the exception, not the set.

The rejection message typically reads: "Your screenshots do not sufficiently show your app in use."

What Triggers This Rejection

• Splash screens as screenshots. If your first screenshot is your app's loading screen or welcome page, Apple will flag it. Reviewers want to see core functionality.
• Pure marketing graphics. A screenshot that is entirely text and background art with zero app UI visible will be rejected. The informal 60/40 heuristic applies here: aim for at least 60% of your screenshot set to show visible app interface. Apple doesn't publish the number, but mostly-marketing sets get rejected under its accuracy guidelines. For what Apple actually checks per frame, see the 60/40 rule breakdown.
• Login or paywall screens. Showing only the screens a user sees before they can actually use the app is considered insufficient.

Note what 2.3.3 explicitly permits: text and image overlays, such as captions and annotated touch points, are fine as long as a real app screen sits underneath [1]. Overlay design is not the risk; missing UI is.

The Fix

Lead with your app's primary value screen. If your app is a task manager, screenshot #1 should show tasks. If it is a fitness tracker, show a workout in progress. Use text overlays and device frames to add context, but the underlying screenshot must be a real screen from your app.

A safe structure for a 5-screenshot set:

1. Hero screen (main feature in action)
2. Secondary feature (another core workflow)
3. Detail or results view (output the user gets)
4. Settings or customization (if visually compelling)
5. Social proof or unique differentiator (still showing real UI)

For a deeper look at how to structure your screenshot narrative for conversions, see Screenshot Story Flows: The 2026 Framework for High Conversions.

Rejection #2: Wrong Screenshot Dimensions

Guideline: Screenshot Specifications [2]

Apple accepts only exact pixel dimensions per device class, and App Store Connect validates them at upload, so a wrong-size file usually fails before review even starts. In 2026 the two required sets are iPhone 6.9-inch (1260x2736 portrait, with 1290x2796 and 1320x2868 also accepted) and iPad 13-inch (2064x2752 portrait) [2].

The 1320x2868 resolution entered the accepted list with the iPhone 17 Pro Max; all three 6.9-inch resolutions remain valid in 2026 [2]. For the full required-versus-optional matrix across every iPhone class, see iPhone App Store screenshot sizes: required vs optional.

If you only provide the 6.9-inch iPhone set, Apple automatically scales it down for smaller iPhone slots (6.5", 6.3", 6.1"). The same applies to iPad: provide the 13-inch set, and Apple scales down for 12.9-inch, 11-inch, and smaller iPads [2].

What Triggers This Rejection

• Exporting at the wrong resolution. A common mistake: exporting at 1284 x 2778 (the 6.5-inch fallback size) when your primary slot expects a 6.9-inch resolution. These are close enough to look correct in your design tool, but App Store Connect will refuse them for that slot.
• Mismatched aspect ratios. Uploading a portrait screenshot to a landscape-only slot (or vice versa) triggers an immediate error.
• Reusing iPhone screenshots for iPad. Apple requires separate iPad screenshots if your app supports iPad, and iPhone dimensions do not match any iPad slot [2].

The Fix

Always export at the exact required pixel dimensions. No rounding. No "close enough." The two sizes that cover every iPhone and iPad submission in 2026:

• iPhone: 1260 x 2736 pixels (6.9-inch, portrait)
• iPad: 2064 x 2752 pixels (13-inch, portrait). For the full breakdown of when the legacy 12.9-inch slot still matters, see iPad Pro 13-inch vs 12.9-inch screenshot specs.

If your design tool outputs at a slightly different resolution (common with Figma exports at non-integer scale factors), use an image processing step to crop or resize to exact dimensions. For the complete dimension reference across all device classes including Google Play, see the App Store screenshot sizes guide.

Rejection #3: Misleading or Inaccurate Screenshots

Guideline: 2.3.1, 2.3.2 [1]

Apple reviews your screenshots against your actual app binary. If a frame shows a feature that isn't in the submitted build, a paywalled screen presented as free, or a fabricated rating or stat, it reads as misleading metadata and gets rejected. The fix is to capture every frame from the build you are submitting, disclose anything paid (2.3.2) [1], and substantiate any number you show.

For the full breakdown of Guideline 2.3.1, including unbuilt roadmap features, post-redesign drift, paywalled UI disclosure, fabricated reviews and press badges, and the AI-screenshot trap, see why misleading App Store screenshots get rejected. Subscription apps have an extra alignment problem (screenshots need to pre-sell the paywall, not just disclose it), covered in the subscription app screenshots guide.

Rejection #4: Non-iOS Platform References

Guideline: 2.3.10 [1]

Guideline 2.3.10 rejections hit developers who ship on both iOS and Android: Apple's rule says "don't include names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata" [1]. Any Android device frame, Google Play badge, or "also on Android" caption in an App Store screenshot triggers it.

What Triggers This Rejection

• Android device frames. Using a Samsung Galaxy mockup in your App Store screenshots. It sounds obvious, but it happens when developers reuse design assets across platforms.
• "Also available on Android" text. Any mention of Google Play, Android, or competing platforms in your screenshots or description.
• Non-iOS status bars. Your screenshot shows an Android-style notification bar or navigation buttons at the bottom. Apple reviewers are trained to spot this.
• Third-party store badges. Including "Get it on Google Play" badges or any alternative distribution channel references.

The Fix

Maintain completely separate screenshot assets for each platform. If you are building for both iOS and Android, create two independent sets of screenshots. Do not copy text overlays, device frames, or captions between platforms without checking for platform-specific references.

For the full breakdown of Guideline 2.3.10, including every element that trips it (Android frames, Google Play badges, leftover "Back to TestFlight" buttons) and what to show instead, see why other-platform references get App Store screenshots rejected.

For Google Play screenshot requirements (which have their own distinct rules), see Google Play Screenshot Sizes: Every Dimension (2026).

Rejection #5: Localization Mismatch

Guideline: 2.3 (accurate metadata) [1]

A localization mismatch rejection happens when your listing claims a language your screenshots don't deliver: a Japanese description with English-only screenshots, or Spanish captions over English app UI. There is no numbered "localization guideline"; these get cited under Section 2.3's requirement that metadata accurately reflect the app's core experience [1].

What Triggers This Rejection

• English screenshots in non-English storefronts. You localized your description into 10 languages but submitted the same English screenshots everywhere. Apple may flag this as low-effort localization.
• Mixed-language screenshots. Your caption text is in Spanish, but the app UI in the screenshot shows English. This signals that the app itself may not be localized, confusing potential users.
• Placeholder or machine-translated text. Captions with obvious translation errors or placeholder text ("Lorem ipsum") in localized screenshots.

The Fix

For each language you support in App Store Connect, create screenshots that show the app UI in that language. This means capturing screenshots from each locale of your app, or at minimum, updating the caption overlay text to match the storefront language.

This is the point where manual screenshot workflows break down. Five screenshots, two device classes, ten languages: that is 100 unique screenshot assets. For strategies on managing this at scale, see App Store Localization 2026: The Complete Global Growth Guide.

Rejection #6: Prohibited Claims in Screenshots

Guideline: 2.3.7 [1]

Prohibited-claim rejections come from caption text, not imagery. Guideline 2.3.7 bans packing metadata with "trademarked terms, popular app names, pricing information, or other irrelevant phrases," and states that metadata "should not include prices, terms, or descriptions that are not specific to the metadata type" [1]. Screenshot captions count as metadata.

What Triggers This Rejection

• Price claims. Including "$0.99" or "Free" in your screenshots. Prices vary by region and can change, so a price baked into an image is inaccurate the moment conditions change.
• Unverifiable superlatives. "#1 App" or "Top Rated" without documented evidence. Apple's subtitle rules call out "unverifiable product claims" explicitly [1], and reviewers apply the same standard to caption text.
• Trademarked terms. Using competitor app names or trademarked terms in your screenshot captions to game search results.

The Fix

Keep screenshot captions focused on describing features and benefits. "Track your workouts" is safe. "The #1 workout tracker" is not (unless you have documentation to prove it). Never include pricing, discount percentages, or time-limited offers in screenshot images. And skip "Rate us 5 stars" overlays entirely: they describe the store, not the app, and add nothing a browsing user needs.

Rejection #7: Age-Inappropriate Screenshot Content

Guideline: 2.3.8 [1]

Guideline 2.3.8 requires all screenshots, icons, and previews to "adhere to a 4+ age rating even if your app is rated higher" [1]. A game rated 17+ for violence still needs storefront screenshots appropriate for any audience; Apple's own example is to "select images that don't depict a gruesome death or a gun pointed at a specific character" [1].

What Triggers This Rejection

• Violent imagery in screenshots. Graphic violence, weapons pointed at characters, or death scenes, even in a game rated for mature audiences.
• Suggestive content. Screenshots showing content that would not be appropriate for all audiences.
• Drug or alcohol references. Visual references to controlled substances in screenshot imagery.

The Fix

Choose your most visually appealing, least provocative screens for your App Store screenshots. For games, show environments, character selection, or gameplay mechanics rather than graphic combat scenes. The app itself can contain mature content (with the appropriate age rating), but the storefront presentation must be universally appropriate.

What Causes Google Play Screenshot Rejections?

Google Play enforces a different but overlapping set of rules: screenshots must be JPEG or 24-bit PNG with no alpha channel, each side between 320 and 3840 px, and the longest side no more than twice the shortest [4]. Google's Metadata policy separately bans ranking, price, and promotion claims in graphic assets [5].

Google Play-Specific Traps

• Alpha channel in PNG files. Google Play requires 24-bit PNG with no transparency [4]. If your design tool exports with an alpha channel, the upload will fail.
• Promotion eligibility thresholds. To be considered for featuring and recommendations, Google asks for at least 4 screenshots for apps (3 for games) at 16:9 or 9:16, minimum 1920x1080 or 1080x1920 [4]. Two low-resolution screenshots will publish, but they cap your distribution.
• Promotional claims in images. Google's Metadata policy prohibits "images or text that indicate store performance or ranking, such as 'App of the year,' '#1,' 'Best of Play 20XX,' 'Popular,'" and "images or text that indicate price and promotional information, such as '10% off,' '$50 cash back,' 'free for limited time only'" [5]. It also bans Google Play program claims like "Editor's choice" [5].

What Should You Check Before Every Submission?

A pre-submission audit takes five minutes and covers the seven rejection causes above: exact dimensions per device class, app-in-use content in every frame, no prices or unverifiable claims in captions, platform-exclusive imagery, locale-matched screenshots, and 4+ age-appropriate content on every storefront.

Run through this checklist before every App Store Connect and Google Play Console submission:

Dimensions

• iPhone screenshots are exactly 1260 x 2736 px (1290 x 2796 and 1320 x 2868 are the other accepted 6.9-inch sizes)
• iPad screenshots are exactly 2064 x 2752 px (if app supports iPad)
• Google Play screenshots keep every side between 320 and 3840 px, longest side no more than 2x the shortest
• No alpha channel in Google Play PNG files

Content

• Every screenshot shows the app in active use (no splash screens, no login pages)
• At least 60% of screenshots contain visible app UI
• All features shown in screenshots exist in the submitted build
• No planned or unreleased features visible
• Screenshots captured from the same build being submitted

Text and Claims

• No pricing ("$0.99", "Free", "50% off") in any screenshot
• No unverified superlatives ("#1", "Best", "Top Rated", "App of the year")
• No competitor names or trademarks in captions
• No calls to rate or review the app
• In-app purchase features are disclosed per Guideline 2.3.2

Platform Compliance

• iOS screenshots contain no Android devices, status bars, or navigation patterns
• Google Play screenshots contain no Apple devices or iOS-specific UI elements
• No references to competing app stores or distribution channels

Localization

• Each storefront language has screenshots matching that language
• Caption text matches the storefront locale
• No placeholder or machine-translated text visible

Age Rating

• All screenshots are appropriate for 4+ audiences (Apple) or all ages (Google)
• No graphic violence, suggestive content, or drug references in any screenshot

How Do You Stay Compliant Without Manual Checks?

Most screenshot rejections share one root cause: a manual, repetitive process with too many places for human error. Screenshots designed months ago drift from the shipping build, exports land one resolution off, one English set gets reused across ten locales. Removing the manual steps removes the rejection surface.

You designed screenshots in Figma three months ago, your app has changed since then, and you forgot to update the assets. Or you exported at a slightly wrong resolution. Or you reused the same English screenshots across every locale. If one of these has already cost you a rejection, here's how to fix it and resubmit without a new build.

The screenshots need to be the right dimensions, show the right build, in the right language, with the right content rules followed, every single time you submit. For the technical approach to eliminating this manual work entirely, see How to Automate App Store Screenshots in 2026.

AppScreenshotStudio enforces compliance by default. Exports are rendered at exact App Store and Google Play dimensions. Device frames match the target platform. The 60/40 UI visibility rule is built into the layout engine. You do not need to check a list because the tool does not produce non-compliant output. That is one less reason for Apple to reject your next submission.