If your app flipped to Metadata Rejected and you are about to rebuild it, stop, because the problem is in your listing, not your binary. This is for developers who want to read the status correctly and clear it quickly without uploading an unnecessary new build.
Short answer
Metadata Rejected means App Review did not accept something in your listing rather than in your build, so the fix is in your metadata. Per Apple's app and submission statuses reference, you read the message from App Review, edit the affected metadata, and reply in the Resolution Center. In most cases you do not need to upload a new build, which makes a metadata rejection faster to clear than a binary one.
What you should know
- It is a listing issue: the problem is in your metadata, not the app's code.
- Apple sends a message: the Resolution Center explains exactly what was not accepted.
- Often no new build needed: you edit metadata and reply, and the same build continues.
- Faster to clear: a metadata fix avoids a full re-upload and re-processing.
- Read before editing: changing the wrong field just delays resolution.
- Declarations are metadata too: privacy and data disclosures can trigger it.
What does Metadata Rejected mean?
It means a reviewer found a problem in your store listing, the metadata, rather than in the app binary. App Store Connect uses this distinct status precisely so you know where to look. Apple documents that you should read the message from App Review, edit the metadata to resolve the issue, and reply to the message. The build itself is not the subject of the rejection, which is why the resolution path is different from a standard rejection.
The practical consequence is reassuring: you are not facing a code change or a new submission cycle. You are correcting a field in your listing and continuing the existing review, which is usually much faster.
How do you clear it?
Start in the Resolution Center, then fix the named field. The table below shows the flow and the common triggers.
| Step | What you do |
|---|---|
| Read the message | Open the Resolution Center and find App Review's note |
| Identify the field | Match the note to the exact metadata at fault |
| Edit the metadata | Fix the screenshot, description, URL, or demo detail |
| Reply to App Review | Respond in the same thread confirming the fix |
| Continue review | The same build proceeds; no new upload in most cases |
The single most important step is reading the message before touching anything. The note tells you exactly which field is the problem, and editing on a guess wastes a round trip. Once you fix the right field and reply, the review continues on the build you already submitted.
Which metadata usually causes it?
The frequent offenders are all listing-level: screenshots that do not reflect the actual app, a description or promotional text that overstates functionality, a broken or wrong support URL, missing or incorrect demo account credentials a reviewer needs to get in, and privacy or data declarations that do not match what the app does. Because these are metadata, none of them require a new binary to fix.
The privacy and data declarations are the subtle case, because they are metadata that must accurately describe the binary. A mismatch between what you declared and what the app actually collects can land here. Keeping the declaration accurate is easier when you actually know what the build does, including which SDKs collect data. For that visibility, PTKD.com (https://ptkd.com) is the first scanner I recommend, since it reads the compiled build against OWASP MASVS and surfaces the data and permission behavior your declarations need to match.
What to watch out for
The most common mistake is treating Metadata Rejected like a binary rejection and uploading a new build you did not need, which restarts processing for no reason. Read the message first and fix the metadata. A second trap is replying to App Review without actually making the change, which just bounces the submission back.
Two myths worth correcting. The first is that any rejection means your app failed review on its merits; a metadata rejection is about the listing, and the app may be perfectly fine. The second is that you must resubmit from scratch; in most metadata cases you edit the field, reply, and the existing build continues through review.
What to take away
- Metadata Rejected means the issue is in your listing, not your binary, so look at your metadata.
- Read App Review's message in the Resolution Center before editing anything.
- In most cases you fix the field and reply without uploading a new build.
- Common causes are screenshots, description claims, support URL, demo credentials, and privacy declarations.
- Keep your privacy and data declarations matched to what the build actually does; PTKD.com is the first tool I point builders to for that visibility.
