12 Reasons Apple Rejects Your Screenshots and Metadata (and How to Fix Each)

You submitted, waited, and got a rejection that has nothing to do with your code. Something in the listing itself is the problem, and the notice quotes a guideline number without telling you which image caused it.

Metadata rejections are common, frustrating, and almost entirely preventable. Below are the twelve that show up most, what the rejection notice typically looks like, and the specific fix for each. If you are currently blocked, jump to the reason that matches your notice, then read the ten-minute pre-submission check at the end so it does not happen twice.

One reassurance before the list: a metadata rejection is not a strike against your account and does not put your app at risk. It is a correction request. Fix it, reply, resubmit.

Why Metadata Rejections Are So Common

App Review checks two different things: does the software behave, and does the listing describe the software honestly. Developers prepare obsessively for the first and treat the second as an upload step done at midnight before submission.

Apple groups most listing problems under Guideline 2.3, Accurate Metadata, with sub-points covering screenshots, hidden features, name and subtitle, and icon consistency. Google Play's equivalent lives in its Metadata and Store Listing policies. The underlying principle in both cases is identical: a user browsing the store should be able to predict what they will get.

Note the division of labour. Technical failures such as wrong pixel dimensions are usually rejected by App Store Connect at upload time, before a human sees them. Content failures are caught by a reviewer days later. The second kind costs you far more time, which is why the content rules deserve the attention.

1. Screenshots Do Not Show the App in Use

Typical notice: a reference to Guideline 2.3.3, stating that screenshots do not sufficiently reflect the app in use.

This is the single most common screenshot rejection, and it catches good-looking listings. If your images are mostly marketing artwork, big claims over a gradient, lifestyle photography, or a logo with a tagline, and the actual interface is a small element or absent, you will be asked to change them.

The fix: every screenshot should contain a real screen from the app, legible, occupying a substantial part of the frame. Designed backgrounds, device frames and captions are all fine, and are what good listings do. The rule is not that decoration is banned. It is that the app must be visible and recognisable in each image.

Watch for a subtle version of this: heavy blur or heavy overlay on the screen behind text. If the reviewer cannot make out what the app does from the image, it can be flagged even though a screen is technically present.

2. Placeholder or Lorem Ipsum Content

Typical notice: Guideline 2.3, metadata contains placeholder content.

Test data is an instant rejection: "Test User 1", "asdf", empty states, lorem ipsum paragraphs, obviously fake avatars, $0.00 totals everywhere. Reviewers look for this specifically because it signals an unfinished listing.

The fix: populate a demo account with realistic, plausible data before capturing. This is worth doing regardless of review, because credible content converts better. A task app showing three real-sounding tasks beats one showing "Task 1, Task 2, Task 3" for both a reviewer and a browsing user.

3. Features Shown That Do Not Exist

Typical notice: Guideline 2.3.1 for hidden or undocumented features, or 2.3 for metadata that does not match the app.

Showing a screen for a feature that is coming next month, gated behind a flag, or only in the Android build is a rejection. So is a caption promising something the app cannot do. This also covers the reverse: screenshots from a newer design than the build you submitted.

The fix: audit each image against the exact binary being reviewed. If a feature is behind a paywall or a login, mention it in the review notes and supply a demo account so the reviewer can confirm it exists.

4. Device Frames That Misrepresent the Platform

Typical notice: Guideline 2.3.10, metadata referring to other mobile platforms.

Two versions of this. The obvious one is an Android device frame or a Google Play badge in your App Store listing, or the reverse. The subtler one is an iPhone frame that does not correspond to any current device, or a screenshot of the iPad build inside an iPhone frame.

The fix: keep frames matched to the platform and to the device class the screenshot slot is for. Remove other-platform badges entirely from store artwork. It is fine to mention platform availability on your own website, not in the store listing.

5. Price, Ranking or Award Claims

Typical notice: Guideline 2.3.7 or a store listing policy citation on Google Play.

Text such as "Free", "50% off", "#1 Fitness App", "Editor's Choice" or "As seen on" inside screenshot artwork causes problems. Price is displayed by the store and can change, ranking claims are unverifiable and time-bound, and store-awarded badges may not be self-applied.

The fix: strip commercial and superlative claims from images. Say what the app does, not how it ranks. If you have genuine press coverage, that belongs on your landing page where you control the context.

6. Third-Party Trademarks and Logos

Typical notice: Guideline 5.2, intellectual property.

Integration logos are the trap here. Showing Spotify, Instagram, Netflix or a bank's mark in your screenshots implies an endorsement or partnership you probably do not have. Sports team badges, character art and recognisable product photography carry the same risk.

The fix: use generic representations of integrations, or obtain written permission. If your app genuinely integrates with a service, describe it in text rather than displaying the logo, unless that service's brand guidelines explicitly permit the usage you have in mind.

7. Wrong Dimensions or Aspect Ratio

Typical notice: usually an upload error in App Store Connect rather than a review rejection, or a rejected listing update on Google Play.

Apple requires exact pixel dimensions per device class. Google Play is more permissive but still enforces bounds: each screenshot must sit between 320 and 3840 pixels on its shortest and longest sides, with the long side no more than twice the short side, and you need at least two per supported form factor. Play also requires a 1024 by 500 feature graphic.

The fix: export at the required size rather than scaling afterwards, which softens text. Check every dimension against our screenshot size checker or the full size reference guide before uploading.

8. Icon Does Not Match the Listing

Typical notice: Guideline 2.3.8, metadata and icon consistency.

The icon in your build must match the icon in the store listing. A mismatch, even a slightly older version, reads as a bait and switch. Separately, an App Store icon containing an alpha channel will be refused at upload, and an icon that imitates system apps or another product is a design rejection.

The fix: ship the same artwork everywhere, export the 1024 version fully opaque with no rounded corners baked in, and verify at every size. Details in the icon size guide.

9. Age Rating Mismatch

Typical notice: Guideline 2.3.6, inaccurate age rating.

Screenshots showing content that exceeds your declared rating, gambling mechanics, alcohol, violence, mature themes, or user-generated content that could contain any of those, will trigger a rating review. Dating, social and game apps hit this most.

The fix: either raise the declared rating to match what the images show, or change the images. Remember that a chat interface implies user-generated content, which affects the questionnaire regardless of what your screenshots show.

10. Keyword Stuffing in Name or Subtitle

Typical notice: Guideline 2.3.7 for name and subtitle, or 4.3 in aggravated cases.

"Habit Tracker, Fitness Log, Workout Planner, Gym Diary" as an app name is a rejection. So is stuffing competitor names into your subtitle or keyword field. Google Play similarly prohibits keyword-stuffed titles and irrelevant terms.

The fix: a real name, then a benefit-led subtitle inside 30 characters. Put your keyword work in the dedicated keyword field on iOS and the description on Android. Our ASO guide covers how to distribute terms without tripping this, and the character counter keeps you inside the limits.

11. Broken or Missing Support and Privacy URLs

Typical notice: Guideline 1.5 for support URL, or 5.1.1 for privacy.

Both stores require a working privacy policy URL and a support URL that resolves to a real page. A link to a homepage with no support information, a 404, or a policy that does not mention the data your app actually collects all get flagged. Google Play additionally requires the Data Safety form to match your app's real behaviour.

The fix: publish a policy that names the specific data types you collect and matches your privacy labels. If you need one, our free privacy policy generator produces a compliant document from a short form, and the privacy policy guide explains what reviewers check.

12. Preview Video Problems

Typical notice: Guideline 2.3.3 applied to app previews.

App previews are held to a stricter standard than screenshots: they must be captured from the app itself. Marketing footage, live-action video of people using a phone, animated logo intros, and camera-shot device footage are all rejected. Duration and format limits are enforced separately at upload.

The fix: build previews from real screen recordings. Text overlays, transitions and music are permitted, and framing the capture is fine, but the substance must be the app running. The full technical specs are in our preview video specs guide.

What to Do When You Are Rejected

1. Read the guideline, not just the summary. The notice cites a number. Open it. The guideline text is usually far more specific than the message.
2. Ask which asset, if it is not obvious. Reply in Resolution Center with a direct question: which screenshot, which line of metadata. Reviewers do answer, and guessing wastes another cycle.
3. Fix only what was cited. Redesigning the whole listing in response to one flagged image invites new problems.
4. Do not submit a new binary for a metadata-only rejection. If nothing in the code changed, changing the listing and resubmitting for review is faster.
5. Push back when you are right. If the guideline genuinely does not apply, say so plainly with a specific explanation. Rejections are sometimes reversed on a clear reply, and there is a formal appeal route for guideline disputes.
6. Record what happened. Keep a short note of the guideline and the fix. The same trap catches the same team twice.

A Pre-Submission Check That Takes 10 Minutes

Run this before every submission. It is faster than one rejection cycle.

• Every screenshot contains a real, legible screen from the build you are submitting.
• No placeholder text, test users, or empty states anywhere in the images.
• No price, discount, ranking, award or press claims inside the artwork.
• No third-party logos, trademarks or other-platform badges.
• Device frames match the platform and the device class of the slot.
• Dimensions verified against the current requirements, exported not upscaled.
• Icon in the build matches the icon in the listing, 1024 version fully opaque.
• Name and subtitle read as language, not a keyword list, and fit the character limits.
• Support URL and privacy URL both load, and the policy matches your declared data collection.
• Preview video, if any, is genuine screen capture and inside the duration limits.
• Age rating questionnaire matches what the screenshots depict.
• Demo account and review notes provided for anything behind a login or paywall.

Our launch checklist tool covers this alongside the rest of a submission, and the full launch playbook puts it in sequence.

Frequently Asked Questions