Metadata Rejected vs Rejected: the key difference

Apple has two distinct rejection statuses, and knowing which one you got tells you how much work is ahead:

The practical consequence is big. When you're Rejected, you generally have to fix the app, upload a new build, and go back through the queue. When you're Metadata Rejected, you can often edit the offending text or assets in App Store Connect and resubmit the same build — no Xcode, no new upload, and frequently a faster turnaround because the reviewer already has context.

Good news in disguise: a Metadata Rejected status means your code passed. Whatever Apple flagged lives in App Store Connect, where you can change it directly. That's usually a same-day fix, not a development cycle.

What actually triggers a Metadata Rejection

Most metadata rejections come from a short list of recurring causes:

Missing or broken demo account

If any part of your app is behind a login, Apple needs working credentials to review it. A missing demo account, expired credentials, or a login that doesn't work is one of the single most common metadata rejections. Provide a username and password in the App Review Information section, and make sure the account actually works and has data in it. If your app needs a special setup (a code, a specific flow), explain it in the notes field.

Screenshots that don't match the app

Under guideline 2.3.3, screenshots must accurately show what the app actually does. Reviewers reject screenshots that display features not in the build, fabricated or heavily mocked-up UI, wrong device sizes, or content that's really marketing artwork rather than the app. This is a frequent trigger — and an entirely avoidable one. (We go deep on this in what to do when Apple rejects your screenshots.)

Broken support or marketing URLs

The Support URL is required and must resolve to a working page with a way to contact you. A 404, a placeholder, or a link to an unrelated page gets flagged. Same for the Marketing URL and Privacy Policy URL if provided — check every link before submitting.

Description, keyword, or promotional text issues

Keyword stuffing, references to other platforms ("also on Android"), mentions of competitors or pricing that violates guidelines, or a description that promises features the app doesn't have. Promotional text making time-limited claims that aren't true can also draw a flag.

Privacy label / data-collection mismatch

If your App Privacy answers ("nutrition label") don't match what the app actually collects — or contradict your privacy policy — that's a metadata rejection. Apple cross-checks the declared data practices against the app's behavior.

Wrong age rating

An age rating that doesn't reflect the app's content (user-generated content, mature themes, gambling mechanics) gets corrected via rejection.

How to fix it and resubmit

  1. Read the Resolution Center message. Apple tells you the specific guideline and usually the exact field. Don't guess — the message is the fastest route to the fix. Open it in App Store Connect under the rejected version.
  2. Fix the flagged item. Update the screenshots, correct the URL, add working demo credentials, revise the copy — whatever was cited. Because it's metadata, you're editing in App Store Connect directly.
  3. Reply in Resolution Center if it helps. If you believe the rejection was a misunderstanding, or you want to explain the fix, reply with a concise, factual note. If the app needs setup steps to review, spell them out here.
  4. Resubmit — usually without a new build. For a pure metadata fix you can resubmit the existing binary. You'll typically re-enter review; because the reviewer already has context, metadata re-reviews often come back quickly.

If you're unsure whether your issue is metadata or binary, the App Store review status guide breaks down every status and what each one implies about your next step.

Screenshots: the metadata rejection you can fully prevent

Of all the triggers above, screenshot mismatches are both common and completely within your control. The rule is simple: your screenshots must show the app as it actually is. That means real screens from the actual build, correct device dimensions for every size you're submitting, and captions that describe features that genuinely exist.

The fastest way to stay on the right side of that rule is to build your screenshots from your real captures rather than from a marketing mockup. With ezscreenshots you drop your actual app screenshots, pick the correct preset for each required device size, add honest captions, and export the full set in minutes — no account, no export limit, all in the browser. Real screens at the right sizes with truthful captions is exactly what guideline 2.3.3 asks for.

If you got flagged specifically on screenshots, our guide to recovering from a screenshot rejection walks through the fix. And if you're re-checking the whole listing before resubmitting, the submission checklist covers every field a reviewer looks at.

Fix a screenshot rejection in minutes, not a dev cycle.

Mismatched or wrong-size screenshots are a top cause of Metadata Rejected — and since it's metadata, you can fix and resubmit without a new build. ezscreenshots exports accurate, correctly-sized screenshots from your real captures fast. Free, browser-based, no account.

Try ezscreenshots →

Summary