A "Metadata Rejected" status in App Store Connect means the rejection is about your app's store listing, such as screenshots, description, name, keywords, or URLs, not about the binary. The key practical point is that you do not need to upload a new build to fix it: you edit the metadata that was cited and resubmit the same binary. Screenshots are a frequent trigger, usually when they show content the app does not contain or reference another platform, and text issues often involve mentioning other platforms, including prices, or keyword problems. Read the exact reason in the Resolution Center, fix that metadata, and resubmit.
Short answer
Metadata Rejected means the problem is in your store listing, not your app, so the fix is to correct the metadata and resubmit without a new binary. Per Apple's App Store Review Guidelines, metadata must be accurate, which covers screenshots, name, description, keywords, and URLs. The Resolution Center names the exact element, so fix that: replace misleading screenshots with ones that reflect the real app, remove references to other platforms or prices from your text, and correct any broken URL. You keep the same build and resubmit the metadata for review. Screenshots showing content not in the app, and text mentioning other platforms, are the most common triggers.
What "Metadata Rejected" means
Metadata Rejected is a specific status telling you the rejection concerns your app's listing rather than the app itself. Your metadata is everything that describes and markets the app on its product page: the screenshots and previews, the name and subtitle, the description, keywords, promotional text, and the support and marketing URLs. When Apple flags one of these, the status is Metadata Rejected rather than a general rejection.
The distinction matters because it tells you where the fix is. Nothing is wrong with your binary; the reviewer found an issue in how the app is presented, so the correction happens in App Store Connect's metadata fields, not in your code. Reading the status as a listing problem rather than an app problem points you straight at the right place to fix, and it also explains why the fix is usually quick compared with a rejection that sends you back to change the app itself.
Do you need to re-upload the binary?
No. This is the most useful thing to know about a Metadata Rejected status: because the issue is in the metadata and not the build, you fix the cited metadata and resubmit the same binary. There is no need to create a new build, bump a build number, or go through processing again, which makes a metadata rejection faster to resolve than one that requires a new binary.
Practically, you edit the flagged elements in App Store Connect, such as swapping a screenshot or revising the description, and then resubmit for review. The existing build stays attached to the version. This is a real advantage of the metadata status, so do not upload a new binary out of habit; doing so is unnecessary and only adds processing time to a fix that did not need it.
What screenshots trigger rejection
Screenshots are one of the most common metadata triggers, and the usual reason is that they do not accurately represent the app. Screenshots that show content, features, or screens the app does not actually contain are a frequent cause, as are ones that display another platform's device or interface, include pricing or promotional text that does not belong, or show placeholder or misleading content. The rejection message names which screenshots are at issue.
Fix them by making the screenshots reflect the real, current app. Use captures from the actual app on the correct Apple devices, remove any that show features you do not ship or content that misleads, and avoid embedding prices or claims that belong elsewhere. Accurate screenshots are not just about passing review; the guidelines require your listing to represent the app honestly, so aligning the screenshots with what users will actually see resolves the rejection and keeps it resolved.
Text and metadata policy issues
Text elements trigger metadata rejections when they are inaccurate or violate policy. Common causes include mentioning other platforms, such as referencing Android in your description, including prices in metadata fields where they do not belong, keyword stuffing or using irrelevant keywords, and using trademarks or brand names you do not have the right to. Your name, subtitle, description, and keywords all must be accurate and compliant.
Correct these by editing the specific field cited. Remove references to other platforms and any pricing from descriptive text, replace stuffed or irrelevant keywords with relevant terms you can legitimately use, and ensure your name and subtitle are accurate and not infringing. As with screenshots, the standard is honesty and compliance, so aligning your text with what the app actually is, and with the policy, is what clears the rejection.
How to fix and resubmit
The fix follows a simple path. Read the Resolution Center message to identify the exact metadata element and the reason, since that tells you precisely what to change. Edit that element in App Store Connect, whether it is a screenshot, a text field, or a URL, and make sure the change addresses the specific concern rather than making broad edits that miss the point.
Then resubmit for review with the same binary. Because no new build is needed, you simply resubmit the metadata, and if the rejection reason was unclear or you believe it was a mistake, you can reply to the reviewer in the Resolution Center to ask for clarification or explain. In most cases, though, correcting the cited metadata and resubmitting is faster than a back-and-forth, so fix the specific issue and send it back.
Common metadata issues
Most metadata rejections come from a short list. The table below pairs each element with a common issue and its fix.
| Element | Common issue | Fix |
|---|---|---|
| Screenshots | Show content not in the app or another platform | Use accurate, current screenshots |
| Description | Mentions other platforms or includes prices | Remove them, keep it accurate |
| Keywords | Stuffing, irrelevant terms, or trademarks | Use relevant, legitimate terms |
| Name or subtitle | Misleading or infringing | Make it accurate and non-infringing |
| Support or marketing URL | Broken or incorrect | Provide a working, correct URL |
Match your rejection to a row using the Resolution Center message. Each element has a distinct fix, and identifying which one was cited turns a vague Metadata Rejected status into a specific, quick correction you can make without touching your code.
Fix checklist
A short sequence resolves a metadata rejection efficiently. The checklist below covers it.
| Check | Action | Done? |
|---|---|---|
| Read the notice | Identify the exact metadata element cited | [ ] |
| Keep the binary | Fix the metadata without uploading a new build | [ ] |
| Screenshots | Ensure they match the real, current app | [ ] |
| Text | Remove other-platform mentions, prices, and bad keywords | [ ] |
| Resubmit | Resubmit the metadata for review with the same build | [ ] |
The step that saves the most time is not uploading a new binary, since a metadata rejection does not require one. Fix exactly what the Resolution Center cited, keep the existing build, and resubmit, which is the fastest route back into review.
What to take away
- Metadata Rejected means the issue is in your store listing, not your app, so the fix is in App Store Connect's metadata fields.
- You do not need to re-upload the binary; correct the cited metadata and resubmit the same build, which makes it a fast fix.
- Screenshots trigger rejections when they show content the app lacks or reference another platform; use accurate, current captures.
- Text issues usually involve mentioning other platforms, including prices, or keyword and trademark problems; keep metadata accurate and compliant.
- Read the Resolution Center for the exact element, fix it, and resubmit; a metadata rejection is separate from security, which you handle by scanning your build with PTKD.com.
