Can a screenshot get your app rejected?
Yes — and it happens to careful developers, not just spammers. App Review doesn't only test your binary; a whole family of rules, Guideline 2.3 "Accurate Metadata," is aimed squarely at your screenshots, previews, and listing copy. Here are the rules that actually catch people, in plain English, straight from the current guidelines.
The rule you've technically agreed to but probably never read
Guideline 2.3.3 says screenshots "should show the app in use, and not merely the title art, login page, or splash screen." So a carousel of pure brand posters — logo, tagline, zero interface — is a rejection waiting to happen, and so is opening with your login screen.
The second half of the same sentence is the part everyone misses, and it's good news: text and image overlays are explicitly allowed. A designed marketing frame — big headline, colored background, device mockup — wrapped around a real capture of your real UI is exactly what the rule sanctions. What's risky is a frame with no app in it, or "UI" that was drawn in a design tool and doesn't exist in the build the reviewer is holding. Reviewers do compare your frames against the app; a screenshot showing a feature they can't find slides into 2.3.1's "marketing your app in a misleading way" — the clause where the consequences escalate from rejection to removal.
Prices don't belong in the pixels
Guideline 2.3.7 says app names, subtitles, screenshots, and previews "should not include prices, terms, or descriptions that are not specific to the metadata type." That "$4.99/month — cancel anytime" banner in frame three is a literal violation, and it's also operationally dumb: prices vary by storefront and currency, and the day you change your subscription price, a stale screenshot starts advertising a number that's now false — which 2.3.1 separately calls out ("promoting a false price") as grounds for removal.
The adjacent trap is 2.3.2: if a screenshot features levels, items, or capabilities that require an in-app purchase, the listing has to make that clear. Showing your best Pro-only feature with no indication it's paid is the kind of thing that surfaces in review — or in a one-star review titled "bait and switch."
Keep the other platform out of the frame
Guideline 2.3.10: don't include "names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata." The classic ways to trip this are mundane — a hero image reused from your website with both store badges in it, an Android-looking device frame around your iOS capture, a "Also on Google Play" strip in the last frame. If you design one set and export it to both stores, this is the rule that bites: each store wants frames that live entirely in its own world, down to the device the screenshot sits in.
Your app can be rated 17+. Your screenshots can't.
Guideline 2.3.8 requires all metadata — icons, screenshots, previews — to "adhere to a 4+ age rating even if your app is rated higher." Apple's own example: a game that includes violence should pick frames that don't depict a gruesome death or a gun pointed at a character. The same logic reaches dating apps, medical apps, and anything with mature themes: the app can contain it; the listing can't show it. The store page is rated for everyone who can browse the store, not for your audience.
One more rule people find out about the hard way — 2.3.9: you're responsible for the rights to every asset in your icons, screenshots, and previews, and you "should display fictional account information instead of data from a real person." Seed a demo account with invented names before you capture. Your beta tester's real face, email, and running route don't belong on your store page, legally or otherwise.
Previews are stricter than screenshots
If you also run an app preview video, note that its rule (2.3.4) is tighter than the screenshot rule: previews "may only use video screen captures of the app itself" — plus narration and overlays to explain things. Lifestyle b-roll of happy people using phones in a park, concept animations, rendered simulations of the UI: all outside the line. Screen recording or nothing.
Google's version: the quiet penalty
Google Play's metadata policy bans misleading, irrelevant, or excessive content across the listing — title, icon, description, screenshots, promo graphics. Its store-listing guidance gets specific about graphic assets: no performance or ranking claims you're borrowing ("#1," "App of the year," "Best of Play"), and no price or promotion text ("10% off," "free for a limited time") baked into screenshots.
The enforcement style is what makes Play different. Apple sends you a rejection with a guideline number; Google often applies a quieter penalty — a listing that violates the quality guidelines can become ineligible for promotion and recommendation across Play surfaces. No email, no red banner. Your screenshots are "fine," and your app just quietly stops being suggested to anyone. If your Play impressions look inexplicably flat, audit the frames for award badges and discount stickers before you blame the algorithm.
Compliant by construction
None of this restricts good design — every high-converting set you've admired follows all of it. The pattern the rules push you toward (real capture, benefit headline, clean branded frame) is the pattern that converts anyway. It's also exactly how ShotCanvas templates are built: your genuine screenshots front and center inside a designed frame, per-store exports so an iOS set never leaks a foreign device, and headlines that carry the message without a single fake pixel of UI.