App Store Rejections: The Screenshot Compliance Guide for Indie Developers

Apple rejects roughly 30 to 40 percent of first-time app submissions [3]. Not because the code is broken, but because the metadata is wrong. Screenshots that show the wrong dimensions. Descriptions that mention pricing. Device frames from the wrong platform. These are the mistakes that delay launches by days or weeks, and most of them are entirely preventable.

This guide covers every screenshot-related rejection reason Apple and Google enforce in 2026, the exact guideline numbers behind each one, and the fixes that get your app approved on the first try.

Table of Contents

• The Guidelines That 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
• Google Play Screenshot Rejections
• The Pre-Submission Compliance Checklist
• Staying Compliant Without Thinking About It

The Guidelines That Govern Your Screenshots

Apple's App Review Guidelines Section 2.3 [1] contains the rules that cause most screenshot rejections. Every indie developer shipping to the App Store needs to know these specific sub-sections:

• 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 features 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 stuffed into metadata.
• 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 references to other mobile platforms or alternative app stores 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]

This is the single most common screenshot rejection for indie developers. Apple's rule is explicit: screenshots must show your app in use. Not your splash screen. Not your onboarding flow. Not a promotional graphic with no UI visible.

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. Apple's 60/40 rule applies here: at minimum, 60% of your screenshot set must contain visible app interface.
• Login or paywall screens. Showing only the screens a user sees before they can actually use the app is considered insufficient.

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 is precise about pixel dimensions. Even a single pixel off can trigger an upload error or rejection. In 2026, the minimum required dimensions are:

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

What Triggers This Rejection

• Exporting at the wrong resolution. A common mistake: exporting at 1284 x 2778 (iPhone 14 Plus dimensions) when the primary set requires 1260 x 2736 (iPhone 16 Pro Max). These are close enough to look correct in your design tool, but Apple will reject or fail to process them.
• 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. You cannot upload iPhone screenshots to the iPad slot [7].

The Fix

Always export at the exact required pixel dimensions. No rounding. No "close enough." Here are 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)

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 App Store Screenshot Sizes 2026: The Essential 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 feature is visible in a screenshot but does not exist in the submitted build, you will be rejected.

What Triggers This Rejection

• Showing planned features. You designed screenshots for your roadmap, not your current release. The timer feature in screenshot #3 is still in development, but you included it because it looks good. Apple catches this.
• Outdated screenshots after a redesign. You updated your app's UI in version 2.0 but forgot to update screenshots. The old screenshots no longer match what reviewers see when they test your app.
• In-app purchase features shown without disclosure. Your screenshots show a premium dashboard, but the app description does not mention that this screen requires a $4.99 subscription. Guideline 2.3.2 requires explicit disclosure of any features that require additional purchases [1].

The Fix

Re-capture screenshots from the same build you are submitting. Do not use mockups from your design files. If a feature requires an in-app purchase, either label it clearly in the screenshot caption (e.g., "Premium") or mention the requirement in your app description.

A practical workflow: after your final build passes QA, take all screenshots from that build. Not from a development branch. Not from a Figma prototype. From the actual binary you are uploading.

Rejection #4: Non-iOS Platform References

Guideline: 2.3.10 [1]

This one catches developers who ship on both iOS and Android. Apple does not allow any reference to other mobile platforms, competing app stores, or non-Apple devices in your metadata.

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 app 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 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.3, 2.3.7 [1]

If your app listing is localized in Japanese, your screenshots for the Japanese App Store should show Japanese text. Apple flags apps that have translated descriptions but English-only screenshots.

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, 2.3.8 [1]

Apple does not allow certain types of claims in your metadata, and that includes text overlays on your screenshots.

What Triggers This Rejection

• Price claims. Including "$0.99" or "Free" in your screenshots. Prices vary by region and can change, so Apple considers these inherently misleading.
• Ranking claims. "#1 App" or "Top Rated" without verifiable, documented evidence. Apple requires proof for superlative claims.
• Trademarked terms. Using competitor app names or trademarked terms in your screenshot captions to game search results.
• Call-to-action for ratings. "Rate us 5 stars!" in screenshot text violates Apple's policies on rating manipulation.

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, as these become inaccurate the moment conditions change.

Rejection #7: Age-Inappropriate Screenshot Content

Guideline: 2.3.8 [1]

All screenshots, icons, and previews must be appropriate for a 4+ age rating, regardless of the app's actual age rating. This means a game rated 17+ for violence still needs screenshots that would be appropriate for any audience.

What Triggers This Rejection

• Violent imagery in screenshots. Showing 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.

Google Play Screenshot Rejections

Google Play enforces a different but overlapping set of rules [5][6]. Key differences from Apple:

Google Play-Specific Traps

• Alpha channel in PNG files. Google Play requires 24-bit PNG with no transparency. If your design tool exports with an alpha channel, the upload will fail.
• TV screenshots from phone UI. If your app supports Android TV, you must submit screenshots showing the actual TV interface. Phone or tablet screenshots will be instantly rejected [6].
• Promotional claims in images. Google explicitly prohibits screenshots containing "content that reflects or suggests Play Store ranking, performance, price or promotional information" [5].

The Pre-Submission Compliance Checklist

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

Dimensions

• iPhone screenshots are exactly 1260 x 2736 px (or 1284 x 2778 px for 6.5")
• iPad screenshots are exactly 2064 x 2752 px (if app supports iPad)
• Google Play screenshots use 16:9 aspect ratio, under 8 MB each
• 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")
• No competitor names or trademarks in captions
• No calls to rate or review the app
• In-app purchase features are disclosed in the description

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

Staying Compliant Without Thinking About It

Most screenshot rejections come from the same root cause: manual processes. 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.

The pattern behind all these rejections is human error in a repetitive process. 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.