Guideline 2.3: Why Review Rejects Your Screenshots
Most “ASO screenshot” rejections are not a taste debate. They are Guideline 2.3: the frames do not match the binary, the splash is doing the talking, IAP is hidden, or the metadata would fail a 4+ check. Here is the indie checklist.
Quick answer
Why does App Review reject App Store screenshots?
App Review Guideline 2.3 requires screenshots and other metadata to accurately reflect the current app. Common screenshot failures: frames that show UI or features the binary does not include, splash or login-only art instead of the app in use, in-app purchases presented as if they were free, prices or unverifiable claims in the image, metadata that would not pass a 4+ age bar, and logos of other platforms. AI layouts are fine. Invented app UI is not.
- 2.3.1 — do not advertise functionality or a UI the submitted binary cannot show
- 2.3.2 — label paid features, levels, and subscriptions in screenshots and copy
- 2.3.3 — show the app in use, not title art, login, or a splash screen
- 2.3.7 / 2.3.8 — no prices in screenshot type; keep frames suitable for 4+
- Start from real captures. Dress the frame. Never generate the product.
On this page
A rejection that cites “inaccurate metadata” feels personal. It is usually mechanical. The reviewer opens the build, walks the obvious flows, and holds your screenshots next to what they see. When those two products disagree, Guideline 2.3 is the language they already have.
Apple’s App Review Guidelines open 2.3 with the rule indie teams quote least and break most: customers should know what they are getting, so privacy information, description, screenshots, and previews must accurately reflect the core experience and stay up to date. The rest of 2.3 is that sentence, itemized.
The screenshot clauses, in review order
| Clause | What it forbids in a frame | Indie fix |
|---|---|---|
| 2.3.1 | UI, features, or prices the binary does not offer | Capture from the submitted build. Delete invented dashboards. |
| 2.3.2 | Paid items, levels, or subscriptions shown as if included | Mark Premium, or do not lead with a gated screen. |
| 2.3.3 | Title art, login, or splash instead of the app in use | Frame 1 is a real task with real data, not a logo card. |
| 2.3.7 | Prices, terms, or copy that does not belong on a screenshot | Keep dollar amounts and “50% off” out of the PNG. |
| 2.3.8 | Frames that would fail a 4+ age bar, even if the app is 17+ | Crop violence, explicit UI, and “for kids” claims unless you are in Kids. |
| 2.3.9 | Real people’s data, or art you do not have rights to | Use fictional accounts. Do not paste a client’s CRM. |
| 2.3.10 | Android, Windows, or other-store marks in the metadata | No Play badge, no “also on Android” lockup in the iOS frames. |
Review is not grading your Figma file. It is checking whether each frame is a truthful picture of the submitted iOS app, suitable for a public storefront.
AI did not get you rejected. The fake UI did.
Text-to-image tools will draw a settings screen, a live chart, a social feed, and a five-star lockup on demand. None of that is in your binary unless you shipped it. Guideline 2.3.1 is explicit about marketing the app in a misleading way, including promoting content or services it does not offer. A generated interface is the same class of problem as a fake antivirus claim, just prettier.
- Legal: generate backgrounds, device framing, and caption type around a real capture.
- Illegal for review: generate the app. If the reviewer cannot tap to that screen, it does not belong in the set.
- Ratings, download counts, press logos, and revenue figures in a frame have to be true and documentable — or gone.
- The workflow that survives is the one in How to make App Store screenshots with AI: real UI in, layout out, human pass before upload.
Paid features and the 4+ metadata bar
2.3.2 is the subscription-app trap: screenshot one is the unlocked analytics view, the description never says it is paid, and review treats that as inaccurate. Put “In-App Purchase” or a Premium mark on the frame, or lead with the free path the reviewer can complete without a store sheet.
2.3.8 is the one teams forget until Creative Assets season: icons, screenshots, and previews must adhere to a 4+ age rating even when the app itself is rated higher. A 17+ game still needs store art that does not hang a gun on a named character. “For Kids” language is reserved for the Kids Category. Fall Creative Assets inherit the same public-store bar — do not build a header that the screenshot set would already fail.
Pre-upload screenshot review in 20 minutes
Open the binary you are sending
Not a feature-flagged branch. Not last week’s TestFlight. The build in the review slot.
Walk each frame in order
For every screenshot, reach that UI, with the same data, without a hidden debug menu the reviewer lacks. If you cannot, recapture or delete the frame.
Mark anything paid
If the screen is behind IAP, say so on the image or move it later and lead with the free job.
Strip store-illegal type
Prices, competitor names, other-platform logos, unverifiable awards, and “for children” claims unless you are actually in Kids.
Export exact sizes from the honest captures
Rebuild captions and backgrounds in AppGrowthKit without replacing the in-app UI, then upload the store-sized set.
Screenshot rejection questions
Can I use AI at all on App Store screenshots?
Yes, for layout, backgrounds, and caption drafts around real captures of the submitted app. No, for inventing screens, data, ratings, or features the binary does not include.
Are device frames and captions allowed?
2.3.3 explicitly allows text and image overlays. Captions and device presentation are normal. They cannot become a substitute for showing the app in use.
Do I need a separate “review-safe” set?
You need the live product-page set to be accurate. If a marketing experiment wants a more aggressive crop, run it only if the binary still backs every claim. Do not keep a rejected-looking set in Connect “just for ads.”
Will fixing screenshots require a new binary?
Screenshot-only metadata can often ship without a code change, but if review already rejected the version you may still be in a resubmit. Fix the frames, note what changed in Review Notes, and do not argue that a generated UI was “aspirational.”
Does Google Play use the same rules?
Play also requires screenshots that demonstrate the actual in-app experience and forbids misleading metadata. The clause numbers are Apple’s. The honesty test is the same: can a reviewer open that screen?
Sources, verified 2026-08-21:
Free tools that help here
App Icon Generator
Drop in one 1024px icon and download every iOS and Android size, ready for Xcode and Android Studio. Runs entirely in your browser - nothing gets uploaded.
ASO Character Counter
Count characters for every App Store and Google Play metadata field against exact store limits. Live counts and over-limit warnings - nothing gets truncated at submission.
Screenshot Beautifier
Add polished backgrounds, padding, shadows, and rounded corners to any screenshot in seconds. Perfect for social posts, docs, and portfolios.
Review compares the frame to the binary. Start from the binary.
AppGrowthKit is built to wrap your real app screens — captions, backgrounds, exact sizes — so the listing you upload is the app a reviewer can actually open.
Try AppGrowthKit for Free