Guideline 2.3: Performance — Accurate Metadata
2.3 rejections are the cheapest ones to avoid and the most annoying to get, because they cost a full review cycle over a text field. The message names the sub-clause:
Guideline 2.3.3 - Performance - Accurate Metadata
We noticed that your screenshots do not sufficiently reflect your app in
use. Specifically, the screenshots display images that do not appear in
the app.The sub-clauses you'll actually meet
| Clause | What it catches |
|---|---|
| 2.3.1 | Hidden, dormant, or undocumented features. Anything the reviewer can't see |
| 2.3.2 | A description that misrepresents what the app does |
| 2.3.3 | Screenshots that don't show the app in use |
| 2.3.7 | App name, subtitle, or keywords that overreach |
| 2.3.8 | Metadata not appropriate for the age rating, or spammy |
| 2.3.10 | Irrelevant third-party platform references — Android, Google Play |
2.3.3 — screenshots
The rule is literal: screenshots must show the app as it runs. What gets rejected:
- Marketing collages where the app UI is a small element in a lifestyle photo
- Screens showing features that aren't in the submitted build
- Placeholder or demo content that a user could never see
- Screenshots from a different platform, or with another platform's chrome
- Text overlays that describe things the app doesn't do
Framing a real screenshot in a device bezel, adding a caption, or using a coloured background is fine and standard. The requirement is that the pixels inside the frame come from your app.
You also need the required sizes. For iOS, iPhone 6.9″ is mandatory; iPad Pro 13″ is mandatory if your build targets iPad. For a Mac app, the desktop set is required. Missing a required set holds the version in Missing Metadata rather than rejecting it — but it stops the submission just as hard.
2.3.1 — hidden features
Anything the reviewer can't reach counts as hidden: a feature behind a promo code, a server-side flag that's off, a beta section, functionality that activates on a date. If it's in the binary, it's reviewable — and if the reviewer finds it later, the tone of the follow-up rejection is markedly worse.
If a feature genuinely can't be demoed, document it in the review notes, or strip it from the build.
2.3.7 — name, subtitle, keywords
- The app name is 30 characters and should be the name. Stuffing it with descriptors ("Notes — Best Free Notepad Task List Planner") is the classic 2.3.7.
- The subtitle describes the app; it isn't a second keyword field.
- Keywords are a 100-character comma-separated field, and it's private — users never see it. Competitor names and trademarks in it are a rejection.
- Don't claim rankings ("#1 productivity app") or reference prices in the name or subtitle.
2.3.10 — the Android mention
The one people trip over without noticing. Your description, keywords, promotional text, or What's New must not reference competing platforms or stores. "Also available on Android", "same great app as on Google Play", "unlike Windows Phone" — all of it comes back. It's usually a leftover from copying marketing copy across platforms.
Fixing it
Nearly all of 2.3 is metadata-only, which means no new build. Edit the field in App Store Connect, reply in Resolution Center, resubmit the same binary. 2.3.1 hidden features are the exception — removing a feature needs a new upload.
Catching it before you submit
This is the category AuditStore covers most completely, because every one of these is a field it can read through the App Store Connect API — across every localization, which is where they hide:
screenshots-<locale>-<displayType>— counts uploads per required display type, per locale, and marks a missing required set Blocking. Requirements adapt to the platform and to whether your build targets iPad.metadata-competitor— lints description, keywords, promotional text and What's New for Android, Google Play, Play Store, Windows Phone and Galaxy Store, and names every locale it found them in. Read-only; it never edits your metadata.description— flags any locale with an empty description, and warns near the 4000-character cap.keywords— flags an unset keywords field, and warns when you're close enough to the 100-character limit that trailing keywords get truncated.whats-new— Blocking when release notes are empty on an update, and correctly silent on a first version.support-url— actually requests the URL and flags one that doesn't answer.
A five-language app has five copies of every one of these fields. Checking them by hand in App Store Connect is where the Android mention survives.
Related
- Version & Metadata checks — the full list
- Guideline 4.3: Spam — screenshots feed the duplicate-similarity match too
- Guideline 2.1: App Completeness