Why Your App Gets Rejected Over Screenshots (And How to Avoid It)
When an app gets rejected, people usually assume it's a functionality or policy issue. In practice, a surprising number of rejections trace back to a single screenshot restarting the whole review process. Indie developers and solo studios are especially prone to this, often because screenshots get thrown together at the last minute. This guide covers the screenshot-related rejection reasons that come up most often, and how to avoid each one.
1. Size Mismatch
This is the most common cause. iOS requires an exact pixel match for each device size, and exporting a rounded canvas value from a design tool is enough to throw that off by a pixel. Google Play is more forgiving, but falling short of the minimum resolution or uploading a PNG with an alpha channel can still get flagged at upload.
How to avoid it: Build your canvas against an accurate device-by-device spec sheet from the start, and double-check the actual pixel dimensions before you upload.
2. Screens That Don't Match the Actual App
If the screen shown in a screenshot doesn't match your actual released build, that's grounds for rejection. This covers in-development placeholder screens, features that haven't shipped yet, or design mockups used as-is. Reviewers install the actual app and compare it against your screenshots, so even a small mismatch can read as misleading.
How to avoid it: Only use screens captured from the exact build you're submitting for review.
3. Wrong Platform UI Showing Through
This happens when an iOS screenshot still has an Android status bar, a different platform's notification icons, or a back button that doesn't belong. Developing for multiple platforms at once makes it surprisingly easy to grab the wrong capture and upload it without noticing.
How to avoid it: Keep capture files clearly separated by platform, and confirm the status bar and system UI match the target platform right before upload.
4. Placeholder Text
This is when dummy text like "Lorem ipsum" or an unfinished line like "sample text goes here" shows up in a submitted screenshot — usually because temporary text from development never got swapped out before the capture was used.
How to avoid it: Fill every text field with real, usable example content before you capture anything.
5. Other Common Reasons
| Reason | Description |
|---|---|
| Overstated marketing copy | Exaggerated claims or unverified numbers unrelated to actual functionality |
| Unverified licensed material | Unlicensed fonts, images, or characters used as decoration in a screenshot |
| Not enough images | Falling short of the platform's minimum image count |
| Screenshots from a different app | Uploading the wrong capture while juggling multiple projects |
6. Banned Text in Google Play's Feature Graphic and Icon
The feature graphic (1024×500) and app icon face stricter review than regular screenshots. Any of the following can get you rejected:
| Type | Examples |
|---|---|
| Ranking / award claims | "#1 App," "Winner of [award]," "Best App" — unverified ranking or award claims |
| Promo / pricing copy | "50% off," "Free trial," "Download now" — promotional or pricing text |
| Call-to-action text | "Click now," "Install" — button-style text that directs a specific user action |
| Emoji / excessive decoration | Emojis, fake star ratings, or badge-style decoration on the icon or feature graphic |
Because the feature graphic and icon sit directly on top of the store's own UI, decoration that imitates real UI elements — star ratings, badges, buttons — reads as fake UI and can get flagged on that basis alone.
7. Steam Capsule Rules
Steam header, main, and small capsule images are restricted under Steamworks policy to essentially artwork and the game's name.
- Review scores, star ratings, or phrases like "Overwhelmingly Positive" are not allowed directly on a capsule image.
- Promotional or award copy like "Launch Sale" or "Award Winner" also isn't allowed on capsules.
- Capsules should stay focused on artwork — promotional information belongs in the store page body copy or a separate announcement.
Stripped down, the principle across both platforms is the same: avoid text that claims performance or achievement, and avoid decoration that imitates real UI. Sticking to artwork and the product name is the safest approach on any platform.
What to Watch for on Resubmission
Most screenshot-related rejections just require swapping the image and resubmitting — but that puts you back at the end of the review queue, and the added wait time matters more than it looks like it should when you're working against a launch date. Double-checking sizes and screen content before your first submission ends up saving time overall.
Matching sizes by hand is where mistakes creep in — StoreShot builds screenshots against exact device specs and can export the full iOS and Android set in one pass, which helps cut down on this category of error.
Takeaway
Most screenshot-related rejections aren't design problems — they're basic checks that get skipped: wrong size, screens that don't match the real app, wrong-platform UI, or placeholder text. Confirming three things before submission — that your captures are from the actual review build, that your pixel dimensions are exact, and that all your text is real — prevents the vast majority of these rejections.