Metadata Rejected vs Rejected: the difference, and why one needs no new build

Metadata Rejected means Apple's objection is to something you can type or upload from a browser. Rejected means the objection is to the app itself.

The practical difference: METADATA_REJECTED needs no new build. You fix the text or the screenshots, resubmit the same binary, and you are back in the queue in minutes. REJECTED usually means a code change, a new build, another upload, another processing wait.

Confusing the two costs you an afternoon rebuilding an app that was never the problem.

What lands in each

METADATA_REJECTED typically covers:

Screenshots that do not show the actual app, or show a device frame Apple objects to
Description or keywords making claims the app does not support
A demo account that does not work, or missing review notes
Age rating that does not match the content
Support or privacy policy URLs that 404
App name or subtitle problems, trademark references, keyword stuffing

REJECTED typically covers:

Crashes and bugs the reviewer hit
Guideline breaches in behaviour: private APIs, misuse of a permission, payment flows outside in-app purchase
Missing functionality, an app the reviewer judged too thin
Sign-in and account-deletion requirements
Anything requiring the app to do something different

The boundary is not always where you would draw it. A rejection for a permission prompt that does not explain itself might come through as either, depending on whether the fix is your Info.plist string or your code. Read what Apple actually asked for; the state is a strong hint, not a specification.

Both states unlock the version

This is the part that saves time. Both REJECTED and METADATA_REJECTED return the version to an editable state, the same set that includes PREPARE_FOR_SUBMISSION and DEVELOPER_REJECTED.

So in both cases you can immediately change:

Description, keywords, promotional text, what's new
Screenshots and app previews
The attached build (in REJECTED, that is usually the point)
Review notes and demo credentials

You do not create a new version. You do not bump the version number. You edit the version that was rejected and submit it again. Apple expects that; the version record is designed to make several trips.

Bumping the version number after a metadata rejection is a common instinct and a waste. It produces a fresh version with none of your history on it, and Apple did not ask for one.

Fixing a metadata rejection

Read the message in Resolution Center properly. Not the summary email, the message. It names the guideline and usually names the specific asset or field.
Fix exactly what was named. Resist the urge to also rewrite the description while you are in there. A change the reviewer did not ask for is a new thing to have an opinion about.
Reply in Resolution Center saying what you changed, in one or two sentences. "Screenshot 3 replaced. It now shows the app's own timer screen rather than a marketing render."
Resubmit the same build. The binary is untouched, so there is nothing to upload and nothing to process.
Expect a fresh trip through WAITING_FOR_REVIEW. Resubmission does not preserve your queue position.

Fixing a full rejection

Same first step, read the message, then the fork is whether a code change is genuinely required.

Sometimes it is not. Rejections for missing account deletion, unclear permission strings, or a broken demo account arrive as REJECTED but are fixed in configuration or in the review notes. Check before you rebuild.

When it is a code change: fix, bump the build number, upload, wait for processing, attach the new build to the same version, resubmit. The version number stays the same, only the build number moves.

The one that is neither

INVALID_BINARY looks like a rejection and is not one. No reviewer was involved. Apple's processing pipeline refused the upload, bad entitlements, missing required icons, an unsupported architecture, a bad signature.

Nothing about your listing is at fault, and there is no message in Resolution Center to read. You get an email from the processing system instead. Fix the build, upload again.

Which one do I have?

The email subject lines differ, but the reliable check is the version state in App Store Connect, METADATA_REJECTED and REJECTED are distinct values on the version record and the console renders them differently.

If you are looking at the state and still unsure what to do, ask one question: does the fix require a new binary? If everything Apple objected to can be changed in a browser, you are in metadata territory regardless of which label appeared.

After the fix

Keep the Resolution Center thread. A rejection on the same guideline three releases later reads very differently when you can show what you changed the first time and why the reviewer accepted it.

AppSubmit records every state transition on a release timeline and keeps the rejection text against the version it belongs to, so the second time a guideline comes up you are not reconstructing it from your inbox. The Resolution Center thread holds the same history if you keep it tidy yourself.