App Store Screenshots: Why Misleading Ones Get Rejected

Apple checks every App Store screenshot against the actual build you submit. If a frame shows a feature that isn't in that build, a paywalled screen presented as free, or a rating or press badge you can't substantiate, it trips Guideline 2.3.1 and your metadata gets rejected. The fix is to make every frame something your binary can back up.

The reason this catches careful developers is that the screenshot and the build are produced by different people at different times. A designer mocks up the perfect frame in Figma while the feature is still on the roadmap. Marketing keeps last quarter's screenshots after the app got redesigned. Both look polished. Both fail the one test a reviewer applies: open the app, and check whether it matches.

TL;DR:

• Screenshots are metadata, and metadata must "accurately reflect the app's core experience" under Guideline 2.3 [1]. A frame that claims something the build doesn't have is misleading metadata.
• The usual triggers: roadmap features that haven't shipped, frames left over from an old UI, paywalled features shown without disclosure (2.3.2), and fabricated reviews, ratings, or press numbers.
• This is a metadata rejection, so the fix is almost always a screenshot swap and a resubmit of the same build, not a new binary.
• The mental model that prevents all of it: before you upload, diff every frame against the app a reviewer will actually open.

The full screenshot rejection guide walks every cause in order. This post goes deep on one of them: the misleading-or-inaccurate class, where the frame and the build disagree.

Table of contents

• What makes an App Store screenshot "misleading" to Apple?
• Which screenshots get flagged as inaccurate?
• Do paywalled features need to be disclosed in screenshots?
• Can you put reviews, ratings, or press badges in App Store screenshots?
• Do AI-generated screenshots risk a misleading-metadata rejection?
• How do you keep your screenshots accurate before you submit?

What makes an App Store screenshot "misleading" to Apple?

A screenshot is misleading when it shows something a reviewer can't find in the submitted build. Apple treats screenshots as metadata, and Section 2.3 says your "screenshots, and previews accurately reflect the app's core experience" [1]. So the test isn't whether the frame looks honest. It's whether the app behind it does the thing the frame implies.

That framing matters because it turns a vague rule into a concrete check. Reviewers download your binary and use it. When a screenshot advertises a feature, a screen, or a result, they look for it in the app. If it's there, the frame is accurate. If it isn't, Guideline 2.3.1 applies: "marketing your app in a misleading way, such as by promoting content or services that it does not actually offer (e.g. iOS-based virus and malware scanners) or promoting a false price" is grounds for removal [1]. The escalation clause is blunt about repeat offenders: "if you're dishonest, we don't want to do business with you" [1]. The practical takeaway is to stop thinking of screenshots as marketing art and start thinking of them as a claim your build has to honor.

Which screenshots get flagged as inaccurate?

Four patterns account for most of these rejections, and all four are versions of the same frame-to-binary mismatch. A feature that hasn't shipped, a frame from an old UI, a gated screen shown as free, or a fabricated number. Each one says something the reviewer's copy of the app won't confirm.

Here is how each maps to what a reviewer actually does, and the fix:

The leftover-UI case is the quiet one. A feature shipped in version 2.4, got removed in 2.7, but the 2.4 screenshots are still attached to the listing. Re-uploading your own old screenshots is one of the easier ways to inherit a rejection, and a redesign is exactly the kind of refresh trigger worth building into your release checklist so the set never drifts from the build.

Do paywalled features need to be disclosed in screenshots?

Yes. If a feature in your screenshot requires an in-app purchase, the screenshot or description has to say so. Guideline 2.3.2 is explicit: "If your app includes in-app purchases, make sure your app description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases" [1]. A premium dashboard shown as if it's the default experience is inaccurate metadata.

This is where subscription apps get caught most often. The most impressive screens are usually the paid ones, so they end up in frames one through three, presented with no indication that a free user never sees them. The fix is small: add a "Premium" tag to the frame, or state the requirement in the description. You don't have to hide the paid experience, and you shouldn't, because pre-selling the paywall is part of what converts. You just have to be honest that it's paid. The subscription screenshot sequence covers how to show the paid value and stay inside 2.3.2 at the same time.

Can you put reviews, ratings, or press badges in App Store screenshots?

Only if they're real and you can prove them. Social proof in a screenshot is a legitimate, high-converting layout. The risk is not the design. It's putting a number or a claim in that frame that your app or company can't substantiate, which turns the frame into the misleading metadata Section 2.3 and Guideline 2.3.1 are written to stop [1].

Concretely, the design pattern is fine: a social-proof frame that surfaces ratings, testimonials, or "as featured in" logos can earn the install. The problem is fabricating the contents. A "4.9 stars from 12,000 reviews" badge on a day-one app with three reviews, an "As seen in Forbes" line when you weren't, a "#1 Finance App" claim you don't hold, or invented download and revenue counts are all claims a reviewer can check and you can't back. Guideline 2.3.1 calls out "promoting content or services that it does not actually offer" and treats repeated dishonesty as grounds for losing your developer account [1]. The safe version is the boring one: show social proof you can document, and if you don't have the numbers yet, use a benefit-led frame instead of an invented statistic. Real and smaller beats impressive and unverifiable.

This is the line worth internalizing for any team using a screenshot generator. A mockup that bakes in a glossy "50k five-star reviews" badge looks great in a design tool and is exactly the kind of unsubstantiated claim that fails review once it's attached to a real listing.

Do AI-generated screenshots risk a misleading-metadata rejection?

They can, if you let the tool invent app content. AI image tools will happily render a UI that looks plausible but doesn't exist in your build, and a "dashboard with live charts" frame for an app that has no such screen is the exact frame-to-binary mismatch Guideline 2.3.1 rejects [1]. The model doesn't know what your app does; it only knows what you prompted.

The accurate way to use these tools is to start from your real screens. Upload the actual app screenshots, then iterate on the framing, captions, device presentation, and background, not on the app content itself. The screen inside the frame stays the screen you ship; everything around it is where the design work happens. That keeps the loop honest: you're refining how the real app is presented, not generating an app that doesn't exist. It also happens to be the workflow that survives review, because the frame and the binary never diverge in the first place. When you build a set this way, the app in frame one is the same app a reviewer opens.

How do you keep your screenshots accurate before you submit?

Run one pass before every upload: open the build you're about to submit, then walk each frame and confirm the app can do what the frame claims. Screenshots are metadata you attach per localization in App Store Connect [2], so a mismatch is a metadata problem you can catch at your desk, not a code problem.

A short pre-submission diff catches the whole class:

• Capture from the submit build, not a branch or a prototype. After your final build passes QA, take every screenshot from that exact binary. Not from a development branch, not from Figma.
• Re-export after any UI change. If the app was redesigned since the last release, the old set is now inaccurate by definition.
• Tag or disclose anything paid. Every gated screen needs a "Premium" label or a line in the description (2.3.2) [1].
• Substantiate every number. Ratings, review counts, rankings, press, and revenue figures all have to be true and documentable.
• Cut fictional UI. If a frame is pure illustration with no real screen, replace it with the app in use (2.3.3) [1].

Get this pass right and you rarely see this rejection. If one has already landed, the recovery is faster than it feels, because a screenshot rejection is a metadata rejection: you edit the images and resubmit the same build, usually the same day. The rejection fix and resubmit guide covers that path, and the screenshot best practices cover the rest of the per-frame review rules, including the 60/40 visibility line that sits right next to accuracy. When you build a fresh set, the screenshot builder keeps your real screens in front of you as you iterate, so the frame never drifts from the app you actually ship.