App Store Metadata Rejected? How to Fix Guideline 2.3 Issues

Quick answer: "Metadata Rejected" means App Review found a problem in your product page, not in your binary: screenshots, previews, name, subtitle, keywords, description, What's New or privacy answers. Apple's instructions are to read the message, edit the metadata to resolve the issue, and reply to App Review. You can resubmit the same build; no new upload is needed.

App Store Connect uses two different rejection statuses:

"Metadata" covers more than the description. In practice, it includes:

• Text: app name, subtitle, keywords, description, promotional text and What's New.
• Visuals: screenshots and app previews, for every display size and every localization.
• App information: category, age rating answers, App Privacy details, support and privacy policy URLs.
• Review information: notes and demo account details.
• In-app purchase metadata: display names, descriptions and review screenshots.

The app icon is the exception: on iOS it ships inside the build's asset catalog, so an icon problem needs a new build. For crashes, privacy and payment rejections, see App Store rejection reasons.

Guideline 2.3, Accurate Metadata, opens with the principle: customers should know what they're getting, so your description, screenshots, previews and privacy information must reflect the app's core experience and stay up to date with new versions. The sub-rules reviewers cite most:

Guideline numbers occasionally shift when Apple revises the document, so always read the number and wording in your rejection message against the current guidelines.

Screenshots cause many metadata rejections because they're seen in every locale and on every device. The App Store screenshot guidelines explain each rule in depth; here are the usual offenders, with fixes:

1. No app in use. A set that's mostly brand art, a splash screen or a sign-in page breaks 2.3.3. Fix: make sure each screenshot shows a real screen from the app; captions and backgrounds can frame it but shouldn't replace it.
2. UI that isn't in the build. A redesigned home screen from your next release, or a feature still behind a flag. Fix: capture from the exact build you submitted.
3. Other platforms. An Android phone frame, a "Get it on Google Play" badge, or "Also on Android" text (2.3.10). Fix: use Apple device frames or go frameless.
4. Real personal data. A real customer's name, email or photo in a list (2.3.9). Fix: use fictional demo accounts.
5. Unlabeled premium features. The best screen in your set is behind a paywall, with no hint (2.3.2). Fix: add a small "Pro" label or mention it in the caption.
6. Mature imagery. Fine for a 17+ app inside the product, not in the screenshots (2.3.8). Fix: pick tamer screens for the store.
7. Placeholder text. Lorem ipsum, "Headline here", or untranslated captions in a localized set. Fix: check every locale, not just English.

Before and after, for a fitness app: a first screenshot with only a logo and "The #1 Workout App" becomes the workout timer screen with the caption "Guided workouts in 10 minutes". The new version shows the app in use and drops an unverifiable ranking claim. More examples are in App Store screenshot mistakes.

• Trademarks and competitor names in the name, subtitle or keywords field (2.3.7). Remove them; the keywords field guide covers safe alternatives.
• Pricing words in the name or subtitle, such as "Free" or "50% Off". Move offers to promotional text or in-app events.
• Features that don't exist or are only planned. Describe what's in the build.
• Other platforms mentioned in the description or What's New.
• Generic release notes such as "Bug fixes and improvements" for an update with new features. Say what changed; App Store release notes has examples.
• Wrong category for the app's main purpose (2.3.5).

1. Open the app in App Store Connect and click the link about unresolved issues at the top of the page.
2. In the In Progress section, click Resolve next to the submission and read the full message. Note the guideline numbers and any attached screenshots.
3. Fix every instance, not just the one quoted. If one screenshot shows an Android frame, check every display size and every localization.
4. Edit the fields on the version page or App Information. Screenshots are editable while the version is in the Metadata Rejected state.
5. Click Reply to App Review and list exactly what you changed. Attach screenshots if they help.
6. Resubmit the submission with the same build.

A reply that works well is short and specific:

Sometimes the reviewer misreads a screenshot or a claim. If you believe your metadata complies:

• Reply to App Review first with a clear explanation and evidence, such as a link to the setting where the feature lives or a screen recording.
• If that doesn't resolve it, you can appeal to the App Review Board. Apple asks for specific reasons your submission complies, answers to any outstanding questions, and only one appeal per submission.

Changing the metadata is usually faster than appealing. Save appeals for cases where the change would hurt your product page or the reviewer clearly misunderstood the app.