A metadata-only rejection can often be corrected in App Store Connect without uploading a build. Fix the exact rejected field, verify every localization, and explain what changed.
The short version
- A metadata-only rejection can often be corrected in App Store Connect without uploading a build.
- Confirm that Apple rejected metadata rather than executable behavior. The item status and reviewer message should support that classification.
- Identify the field and localization cited by Apple.
- Do not promise approval; give App Review a testable path.
Identify the rejected metadata field
“Metadata Rejected” identifies a review surface, not the defective field. Open Apple’s message and item status, then name the exact localisation and field: screenshot, preview, description, subtitle, promotional text, name, or URL.
Compare the rejected listing with the selected build as a reviewer sees it. For every claim, identify the in-app screen that proves it. Mark claims that require a subscription, account state, region, hardware capability, or unreleased feature.
Diff the product page against the reviewed build
Edit only the inaccurate field family first. Check all submitted localisations and device sets because correcting one English field can leave the same promise elsewhere. Save the changes and reopen the version to verify they persisted.
- Identify the field and localization cited by Apple.
- Compare each claim and asset with the submitted build.
- Edit only the inaccurate field family.
- Save and verify the change in every affected locale and device slot.
- Reply with a literal list of the saved metadata changes.
Your evidence is a before/after field diff plus the path in the current build that supports the final wording. Internal marketing rationale does not establish product-page accuracy.
Choose a listing edit or product correction
If the app already behaves correctly, a listing edit may keep the selected binary. If you choose to make the advertised feature real, correct an in-app label, or add bundled disclosure, the product changed and another build is required.
| Situation | Next action | New build? |
|---|---|---|
| Description, subtitle, keywords, or promotional text | Edit and save metadata | Usually no |
| Screenshot or app preview mismatch | Replace the asset in correct slots | Usually no |
| Support or privacy URL wrong | Publish and save the correct URL | Usually no |
| Feature promised but absent | Remove claim or add feature | Depends |
| Hidden behavior in the binary | Correct or disclose behavior | Often yes |
Use the field-level diff to decide: retain the binary for a truthful listing edit, but submit another build when the advertised product behaviour itself changes.
Confirm the rejected surface
Open the message and status reference. A label such as Metadata Rejected points toward editable product-page or review information. A runtime bug described alongside a metadata concern may still require a build.
Name the exact version, localization, device family, and field before editing.
Compare the listing with the build
Every screenshot, preview, price statement, feature claim, platform reference, and support promise should be reproducible in the reviewed version. Check remote flags and account tiers that might hide the advertised screen.
Remove claims that belong to a future version. Adding the claimed feature is a different choice and changes the binary.
Edit the narrow field family
Replace inaccurate screenshots with captures from the current iOS build. Correct names, subtitles, descriptions, keywords, promotional text, URLs, and What’s New copy where relevant.
Review every localization and screenshot size. Saving one language does not repair a mismatch left in another submitted language.
Tell Apple what changed
List each changed field and the specific correction. State that no new build was required only when the binary did not change. Give the reviewer a path if the corrected claim still refers to a non-obvious feature.
Keep the reply factual. There is no need to defend old copy once it has been corrected.
If the reviewer note crosses failure classes, use the App Store rejection map to separate the app store metadata rejected symptom from unrelated issues.
After classifying this app store metadata rejected case, use the post-rejection workflow to sequence the App Store Connect actions.
Build a field-level discrepancy list
Create one row per rejected field and localisation. Copy the current value, the reviewer’s concern, the in-app evidence, and the proposed final value. This prevents a broad rewrite from introducing fresh claims while missing the original mismatch.
Check dependencies between fields. A subtitle claim may also appear in screenshots, promotional text, or the description. A support URL may be correct in one locale and stale in another. Correct the family consistently without turning the cycle into an unrelated rebrand.
Use conditional claims carefully
When a feature requires payment, login, hardware, region, or user-created data, the listing must not present the depicted state as universally available. Add accurate context or choose an image and wording that represent the default path. Verify the condition in the selected build.
Do not solve an inaccurate statement with vaguer superlatives. Prefer concrete capabilities that a reviewer can reach and users can understand.
Read the final listing as a first-time user who has not seen your roadmap. Remove dates, availability language, awards, comparisons, or performance statements that the reviewed build and submitted evidence do not support. Keep the correction factual rather than replacing one unsupported claim with another.
Verify the saved listing
After editing, reopen the version and each affected localisation. Compare the final fields with the selected build and capture a concise before/after record. Confirm that no in-app label still contradicts the listing.
Tell Apple which exact fields and locales changed. If no binary changed, say so and give the in-app path supporting the final claim. For image-specific work, follow the screenshot mismatch guide.
Check shared metadata separately from version-specific metadata before closing the draft. A corrected subtitle does not repair an outdated promotional text field, and changing the default language does not guarantee that every localisation inherited the same claim. Keep a small matrix of field, locale, previous wording, final wording, and the build screen that proves it. That record makes the reply precise without asking the reviewer to compare the entire product page again. Include the saved timestamp for the final App Store Connect state.
Verify against Apple before resubmitting
Rules and App Store Connect interfaces can change. Reopen the Apple pages that support this decision before you act: App Review Guidelines, 2.3 Accurate Metadata, Reply to App Review messages, App and submission statuses. These are the primary policy and workflow sources used for this guide, opened on 4 August 2026.
FAQ about App Store metadata rejected
What does Metadata Rejected mean?
It indicates a problem with information or assets associated with the submission rather than an automatic finding that the binary itself is broken.
Can screenshots be replaced without rebuilding?
Often yes. Replace them in App Store Connect, then verify every required device slot and localization.
Can I change the description during rejection?
Editable fields can often be corrected while resolving the issue. Follow the current App Store Connect state and Apple’s message.
When does a metadata problem need a build?
When you choose to change app behavior or bundled assets, or when the claimed feature must be added to the binary.
Conclusion
Correct the exact field and localisation, verify each final claim against the selected build, and avoid expanding a narrow metadata cycle into an unsupported rewrite.
Sources and references
- App Review Guidelines, 2.3 Accurate Metadata (accessed 2026-08-04)
- Reply to App Review messages (accessed 2026-08-04)
- App and submission statuses (accessed 2026-08-04)