App Store Screenshot Rejected? Fixing Guideline 2.3.3, 2.3.7 & 2.3.10 Issues

Why screenshot rejections hurt more than they should

A metadata rejection rarely blocks your build for long, but it costs a review cycle, delays a launch date you probably announced, and forces you to redesign creatives under pressure. Most of these rejections trace back to one section of the App Review Guidelines: 2.3 Accurate Metadata.

The principle behind 2.3 is simple: customers should know what they are getting. Your description, screenshots, previews, and privacy information should reflect the app's core experience and stay current with each version. Everything below is a practical reading of that principle for screenshot work. It is not legal advice, and App Review always has the final word.

The guidelines that matter for screenshots

2.3.3 — Show the app in use

Apple's wording is direct: screenshots should show the app in use, not merely the title art, login page, or splash screen. Overlays are explicitly allowed—text captions, touch indicators, Apple Pencil, device frames—so marketing-style screenshots are fine as long as real UI is the star.

Common failures:

• A first frame that is only a logo on a gradient.
• A sign-in screen used because "that's what users see first."
• Frames that are 80% illustration and 20% shrunken UI.
• Stock photos of people with a tiny phone in the corner.

Fix: every frame should contain a recognizable, real screen from the current build. If you want a brand moment, put the logo above real UI rather than replacing it.

2.3.7 — Names, keywords, and no padding

2.3.7 is mostly about the app name, subtitle, and keywords, but it also says metadata such as screenshots and previews should not include prices, terms, or descriptions that are not specific to the metadata type. In practice, screenshot captions get flagged for:

• Specific prices ("Only $4.99!") — prices vary by storefront and change independently of your metadata.
• Competitor or popular app names ("Better than [Brand]").
• Unverifiable superlatives ("#1 budget app," "the best tracker").
• Keyword stuffing in captions that reads like a search query rather than a benefit.

Fix: describe what the user can do, not what you claim to be. "Split bills with friends in seconds" survives review; "The #1 bill splitter, now 50% off" invites trouble.

2.3.10 — Stay focused on Apple platforms

2.3.10 asks you not to include names, icons, or imagery of other mobile platforms or alternative app marketplaces in your metadata unless there is specific, approved interactive functionality. Cross-platform teams hit this constantly because they reuse marketing assets:

• An Android device frame in an iOS screenshot set.
• A Google Play badge in a footer.
• A "Available on Android too" caption.

Fix: keep a separate iOS export. A good mockup workflow makes this cheap—switch the frame and re-export rather than editing pixels by hand. Our device mockup tool and the screenshot editor let you produce clean platform-specific sets from the same source captures.

2.3.2 — In-app purchases must be clear

If a feature you highlight requires a subscription or in-app purchase, your screenshots and description should make that clear. A frame showing premium-only features with no indication they are paid is a classic paywall-related rejection. We cover this in depth in Subscription & Paywall Screenshots: App Store Compliance.

A pre-submission screenshot checklist

Run this before every submission that changes creatives:

1. Real UI in every frame. No splash, no login-only, no title-art-only frames.
2. Current build. UI matches what reviewers will see after installing. Old tab bars and removed features are red flags.
3. No prices or time-limited offers baked into images.
4. No competitor names, no "#1," no "best" unless you can prove it and it's specific (and even then, think twice).
5. No other-platform imagery: Android frames, Play badges, Windows chrome.
6. Paid features labeled when they appear.
7. Correct sizes and no alpha channel. App Store Connect rejects images with transparency. Check pixels with our screenshot checker and look up current dimensions with the screenshot size reference or our 2026 size guide.
8. Localized sets reviewed too. A German caption can carry a forbidden claim the English one doesn't.
9. Privacy-consistent. If a frame shows contacts, location, or health data, your App Privacy answers should cover that data.

How to respond when you're rejected anyway

Read the exact guideline cited. The rejection message in App Store Connect usually names the guideline number and often includes a screenshot of the problem. Don't guess; fix that thing first.

Metadata-only rejections can often be fixed without a new build. When the problem is only in screenshots or text, you can typically replace the assets in App Store Connect and resubmit. If the binary itself is fine, you avoid a rebuild.

Use the Resolution Center thoughtfully. If you believe the reviewer misread a frame—say, a "login" screen that actually shows onboarding content—reply calmly with context. Pointing to the guideline's own wording ("overlays are permitted…") works better than arguing.

Don't sneak it back in. Removing a claim for review and restoring it in the next update tends to cause repeat rejections and erodes trust with review.

Designing screenshots that won't get flagged—and still convert

Compliance and conversion are not opposites. The frames that survive review are usually the ones that convert best, because both reward clarity:

• Lead with an outcome caption over real UI. "See every subscription in one place" plus the actual list view.
• Use specific, checkable claims. "Works offline," "Syncs with Apple Health," "Export to PDF" are concrete and verifiable.
• Let the UI breathe. Crop to the relevant part of the screen instead of shrinking the whole device into a corner.
• Keep text short. Long captions tempt you into claims; short ones force you to pick a benefit.

For a full framework on ordering frames and writing captions, see How to Make App Store Screenshots That Convert.

Quick reference: rejection reason → fix

Bottom line

Most screenshot rejections are avoidable with a five-minute check: real UI in every frame, no prices, no competitor names, no other-platform imagery, and paid features labeled. Build that checklist into your release process, keep platform-specific exports, and you will spend your review cycles on the binary instead of on pixels.