Guideline 2.3 Accurate Metadata: How to Fix Your App Store Listing and Resubmit

What Guideline 2.3 actually means

The core rule: customers should know what they're getting. Apple asks that all metadata, "including privacy information, your app description, screenshots, and previews accurately reflect the app's core experience" and stay current with new versions (App Store Review Guidelines, 2.3).

Rejections usually cite a sub-clause. As of October 2026 (guidelines last updated June 2026), these matter most:

Most 2.3 issues are fixed in App Store Connect, not in code. The exceptions are hidden features and other-platform references inside the app, which need a new build.

Common reasons apps get rejected under 2.3

Reviewers compare each field with the binary. Typical triggers by field:

A recurring surprise: rejection messages quoted in Apple's Developer Forums state that "references to free or discounted services are considered a price reference". Developers report this for "Free" inside an app name and for screenshot banners, and even currency amounts in demo data on screenshots have been flagged, so use neutral sample data (details in the screenshots guide). Unauthorized trademarked terms in keywords can also trigger Guideline 5.2.1 Intellectual Property.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix a 2.3 rejection step by step

1. Check the sub-clause and status. Metadata Rejected means App Review objected to the metadata only; Apple's help says you can resubmit the same build once the issue is fixed. A plain Rejected status for a 2.3.1 or in-app 2.3.10 issue means you need a new build.
2. Audit every locale. Reviewers often quote one example only. Check each localization of the version page (description, keywords, promotional text, What's New, screenshots) and App Information (name, subtitle, category, age rating). With fastlane, fastlane deliver download_metadata pulls all locales for searching.
3. Rewrite name and subtitle. A distinctive brand name with at most one short descriptor; the value proposition goes into the subtitle as a phrase, not a keyword list. Remove price words, "best" and other brands.
4. Clean the keyword field. Comma-separated, no spaces after commas. Remove competitor app names, other companies' names, unauthorized trademarks and irrelevant terms – these are rejection risks. Category names, "app" and words already in your app or company name are not violations, but Apple calls them wasted space. App Store Connect counts bytes, not characters, so accented and non-Latin characters use more of the budget.
5. Match the description to the build. Install the exact build from TestFlight and tick off every feature the description mentions. Delete what isn't there and label paid features ("Premium unlocks...").
6. Remove other-platform references. Search for "Android", "Google Play", "Play Store", "APK" and the names of alternative app marketplaces, and replace screenshots taken on Android devices.
7. Re-check category and age rating against Apple's category definitions and the questionnaire (see below).
8. Write What's New and review notes. List significant changes in What's New. In App Review Information > Notes, describe each new feature with test steps; the current 2.3.1(a) text says generic descriptions will be rejected.
9. Resubmit. Metadata only: save the edited fields, reply to App Review in the same thread with a summary, and click Resubmit to App Review on the submission page if it is shown. Code changed: increment the build number, upload, select the new build in the version's Build section and resubmit.

2.3.1: hidden features, feature flags and review notes

Take 2.3.1 most seriously: its text warns that misleading behavior can lead to app removal and termination of your developer account. Typical triggers:

• Remote config that changes the app after approval, such as swapping native screens for web content or unlocking a different business model.
• Debug or admin menus in release builds, reachable through secret gestures.
• Account or region gating where the reviewer sees a reduced app.
• Listed features switched off in the reviewed build.

Staged rollouts and A/B tests are common; the problem is functionality App Review never saw. Make sure every feature a flag can enable is in the reviewed build, enabled for the review account and described in the notes. Strip debug menus at compile time (#if DEBUG in Swift, kReleaseMode in Flutter, __DEV__ in React Native). For features behind a login, see our 2.1 Information Needed guide on demo access.

2.3.10 in Flutter, React Native and other cross-platform apps

2.3.10 applies even if your app genuinely ships on Android: the iOS listing and build should be about the Apple experience. Cross-platform teams hit it most because assets and strings are shared. Where to look:

• Store copy copied from Google Play ("Also available on Android").
• Screenshots and previews from an Android emulator, with Material status bars or Pixel frames.
• In-app strings: onboarding, share texts ("Get it on Google Play"), QR codes or rating prompts linking to the Play Store.
• Web help pages inside the app that show a Google Play badge.

Make content platform-aware: Platform.isIOS in Flutter, Platform.select in React Native, separate string tables in native code. Neutral wording such as "available on your other devices" is a common alternative.

The exception is specific, approved interactive functionality – for example, a feature that genuinely interacts with Android devices, such as transferring data to them, may qualify. Describe it factually and explain it in the review notes; App Review decides whether it counts. On both stores? See our Google Play metadata policy guide.

2.3.5 category and 2.3.6 age rating: getting them right

Category

Your primary category should describe the app's main function. Classic mismatches: a habit tracker in Medical, a flashcard quiz in Games instead of Education. Change it in App Information > Category. Apple's category definitions point out that choosing an inappropriate category is itself against the guidelines. The Kids category is for apps designed for kids aged 11 and under: select Made for Kids (only offered when the calculated rating is 4+ or 9+) and an age band of 5 and under, 6–8 or 9–11. The choice can't be changed once the app is approved, and the Kids rules in guideline 1.3 then apply to every update.

Age rating

Apple's ratings are now 4+, 9+, 13+, 16+ and 18+. The questionnaire starts with in-app controls (parental controls, age assurance) and capabilities: unrestricted web access, user-generated content, social media, messaging and chat, and advertising. Content questions cover mature themes, medical or wellness topics, sexuality or nudity, violence and chance-based activities. Apple asked developers to answer the revised questions for each app by January 31, 2026 to avoid an interruption when submitting updates, so an app that still has unanswered questions should complete them before its next submission.

Common mistakes: answering "no" to user-generated content because users "only" post comments, ignoring an in-app browser with unrestricted web access, or forgetting ads. Edit under App Information > Age Ratings. If your terms of use or EULA set a higher minimum age than Apple's calculated rating, Apple says you must use Override to Higher Age Rating. Apps with user-generated content also need the moderation features required by guideline 1.2.

How to reply, resubmit or appeal

Reply in App Store Connect

Go to Apps, select your app, click the unresolved issues link, choose Resolve, then Reply to App Review. Replies can be up to 4,000 characters with attachments (App Store Connect Help). List each changed field with old and new values; a before-and-after list saves the reviewer time.

When to push back

Explain politely, with evidence, when the reviewer missed something: a listed feature behind a login, a cross-platform reference that is real interactive functionality, or a name word that is your registered brand rather than a keyword. Attach a screen recording or trademark details.

Appeal

If App Review misunderstood your app, you can appeal to the App Review Board via Apple's App Review page: one appeal per submission, with specific reasons why the app complies, and only after answering any open requests for information. For most 2.3 cases, editing the field is faster. If the rejected version is a bug-fix update and App Review offers to let you resolve the additional issues in your next submission (not available for legal or safety concerns), reply to that offer message in App Store Connect to accept it.

How to avoid 2.3 rejections next time

Metadata is plain text with hard limits, which makes it ideal for CI. Keep it in version control (for example fastlane/metadata/<locale>/ with name.txt, subtitle.txt, keywords.txt, description.txt, promotional_text.txt, release_notes.txt) and lint it before deliver uploads:

• Length checks: name and subtitle 30 characters, keywords 100 bytes, promotional text 170 characters, description and release notes 4,000 characters.
• Blocklist scan: fail on "Android", "Google Play", "APK", price words, "#1", competitor names and "for kids".
• In-app string scan: grep .xcstrings / .strings files, Flutter lib/ and assets/ or React Native sources for the same terms.
• Release notes gate: require What's New and review notes covering each feature merged since the last release.
• Feature-to-listing review before major releases, including the age rating questionnaire when you add chat, ads or a browser.

AI-assisted checks can compare description claims with your feature list, spot keyword stuffing and draft specific What's New text; a human still judges borderline phrasing. Want help? Book a free consultation call with appsubmitter.io, or let our team handle store listing, submission and review communication – even if your code isn't 100% ready (code changes aren't included and are discussed and quoted upfront).

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) and for your feedback regarding Guideline [2.3.x] - Performance - Accurate Metadata.

We have revised our metadata in all localizations ([locales]):

1. App name: changed from "[old name]" to "[new name]", removing [keyword terms / price reference].
2. Subtitle: changed from "[old subtitle]" to "[new subtitle]".
3. Keywords: removed [competitor names / irrelevant terms].
4. Description and promotional text: removed references to [missing feature / other platforms] and labeled [feature] as an in-app purchase.
5. Screenshots: replaced [number] screenshots showing [non-iOS devices / price banners].
6. [If applicable] Age rating / category: updated to reflect [chat / user-generated content]; primary category is now [category].

[If a new build was required] Build [build number] removes [in-app reference / hidden feature]. New features are described in the review notes. Demo account: [username] / [password].

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• App name is a distinctive name of at most 30 characters, with no keyword list, price words or other brands.
• Subtitle is a descriptive phrase without repeated keywords, unverifiable claims or other app names.
• Keywords contain no competitor app names, other company names, unauthorized trademarks or irrelevant terms.
• Promotional text contains no expired sale, false price or other-platform launch news.
• Every feature in the description and promotional text exists in the submitted build; paid features are labeled.
• No locale mentions Android, Google Play or APKs in text, screenshots or previews.
• iOS in-app strings, onboarding, share texts and help pages contain no other-platform badges or links.
• Primary category matches the app's main function.
• Age rating answers cover chat, user-generated content, ads, web access and wellness topics.
• What's New lists significant changes; review notes describe each new feature with test steps.
• No remote-config flag can enable functionality missing from the reviewed build.

Frequently asked questions

Official source: App Store Review Guidelines – 2.3 Accurate Metadata. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.