On this page (8 sections)
Guideline 2.3 — Accurate Metadata
Apple asks that everything shown in the store accurately reflects the app: descriptions, screenshots, previews, name, subtitle, keywords, category, age rating, in-app purchase names and descriptions, and What’s New. The listing is a promise about the build under review.
The Metadata Rejected status
When the status is Metadata Rejected, Apple is telling you the binary does not need to change. Edit the metadata, and resubmit the same build. If the message also cites app behaviour (a crash, a missing feature), you have two problems and the second needs a new build.
Common findings
Screenshots and previews
- Screenshots showing a different platform’s UI, a different app, or features not in this build.
- Marketing composites that do not depict the app in use; previews not captured from the app.
- Screenshots for the wrong device size or with placeholder data.
Product claims
“Best”, “#1”, “award-winning”, “free” for a paid app, or claims about results the app cannot substantiate. Remove claims you cannot back up.
Name, subtitle and keywords
Keyword stuffing in the name or subtitle, other apps’ or brands’ names, references to other platforms. Keep the name to the product; put descriptors in the subtitle honestly; use the keyword field for keywords.
In-app purchase metadata
IAP display names and descriptions must describe what the user gets. Vague “Premium” items and mismatched prices in screenshots are frequent findings.
Age rating and Kids metadata
The age rating questionnaire must match the content, including user-generated content, gambling-like mechanics and unrestricted web access. Kids Category apps have additional metadata rules.
Other-platform branding and What’s New
References to Android, Google Play or other stores in screenshots or text draw 2.3 (and sometimes 5.2). What’s New should describe this version, not repeat the description.
Notes for Review
Notes that are missing, stale or misleading count as metadata. Update credentials and instructions every submission.
Guideline 2.3.1 — hidden or dormant functionality
This is the serious one
2.3.1 covers apps with hidden, dormant or undocumented features, apps that change behaviour after review (remote switches, feature flags that unlock different content), and apps that behave differently for reviewers. Apple treats this as deception. If your message cites 2.3.1, remove the switchable or undocumented behaviour entirely, describe every feature in the notes, and respond with complete transparency. Cosmetic metadata edits will not resolve it.
Same-build resubmission
| Finding | Same build? | What to change |
|---|---|---|
| Screenshots / previews | Yes | Capture from the actual build on the required device sizes |
| Description, name, subtitle, keywords | Yes | Edit in App Store Connect |
| Age rating | Yes | Redo the questionnaire truthfully |
| IAP names / descriptions | Yes | Edit the products; resubmit them with the version |
| Notes for Review / credentials | Yes | Update App Review Information |
| Feature shown in screenshots does not exist in the app | Depends | Remove from screenshots, or build the feature (new build) |
| 2.3.1 hidden functionality | No | Remove the behaviour in a new build; document everything |
Metadata consistency check
- Every screenshot is captured from this build and shows a real screen
- Description lists features that exist and works without superlatives you cannot prove
- Name and subtitle describe the product; keywords live in the keyword field
- Age rating answers match the content, including UGC and web access
- IAP display names and descriptions describe the benefit; prices in screenshots match
- No other-platform branding anywhere
- What’s New describes this version
- Notes for Review are current and the demo account works
ASO vs compliance
Store optimisation and compliance conflict when optimisation means stretching the truth. Keyword-heavy names, competitor brand names and inflated claims may lift impressions briefly and then cost a rejection and, with repetition, more. Optimise inside the guidelines: accurate name, honest subtitle, well-chosen keyword field, screenshots that sell what the app actually does.
What we can fix, and what we cannot
For a Metadata Rejected status we audit the listing against the build: screenshots and previews that show real screens, a description and keywords that match what the app does, an age rating and IAP descriptions that reflect the actual content, and review notes that answer the reviewer’s question. If the mismatch is in the app rather than the listing — a feature that exists only in marketing copy, a dormant mode, a hidden switch — we say so and fix the app, because 2.3.1 is not resolved by editing text. We cannot promise that a corrected listing passes; we can make sure nothing in it contradicts the build.