What a Guideline 2.3 rejection actually means
A Guideline 2.3 rejection means App Review compared your product page to your app and found a mismatch. Apple files 2.3 in the Performance chapter under the heading Accurate Metadata, and the rule is exactly what the heading says: the screenshots, app name, subtitle, keywords, description, preview video, and release notes all have to accurately represent what the app in front of the reviewer actually is and does. The app can be perfectly functional and fully compliant everywhere else and still get rejected under 2.3, because 2.3 is not judging the app - it is judging the gap between the app and the story the listing tells about it.
That framing is good news in practice. Of all the rejections in the numbered-guideline family, 2.3 is usually the cheapest to fix, because in most cases the app is fine and only the listing needs to change. Fields like screenshots, keywords, and the description can be edited in App Store Connect without touching code, which means many 2.3 rejections resolve without building or uploading anything new. The work is figuring out which specific clause the reviewer cited, because Guideline 2.3 is a family of numbered sub-rules and each one points at a different field of your listing.
The clause map: which 2.3 rejection you got
Guideline 2.3 breaks into numbered clauses, and the clause number in your rejection tells you which part of the listing to fix. These are the ones indie submissions hit most often.
The Guideline 2.3 clauses indie apps actually get cited for
| Clause | What it targets | Where the fix lives |
|---|---|---|
| 2.3.1 | Hidden, undocumented, or misrepresented features - the app does something the listing does not disclose, or the listing promises something the app does not do | Description, and sometimes the binary itself |
| 2.3.3 | Screenshots that do not show the app in use - concept art, marketing-only frames, device frames from the wrong platform, or images of a different app version | Screenshot set in App Store Connect |
| 2.3.7 | App name, subtitle, and keyword field - keyword stuffing in the name, other apps' brand names, claims like rankings or price in the name field | Name, subtitle, and keyword fields |
| 2.3.10 | Irrelevant third-party platform references - mentioning Android or other platforms in the listing or inside the app | Description, screenshots, and in-app copy |
| 2.3.12 | Release notes that do not describe what changed - blank, generic, or misleading what's-new text on an update | Release notes field for the version |
If the rejection cites bare 2.3 with no sub-number, read the reviewer's message for which field they quote - it is almost always one of the five above. And if you are still deciding what goes in these fields rather than fixing a rejection, the guides on [writing an App Store description](/blog/how-to-write-an-app-store-description) and [finding App Store keywords](/blog/how-to-find-app-store-keywords) cover the offense; this post is the defense.
Fixing 2.3.3: screenshots must show the app in use
Clause 2.3.3 says screenshots should show the app in use - the actual interface a user will see - not a title card, not concept art, not a mockup of features you have not built. This is the clause fast builders hit most, and the pattern is always the same: the app changed during the final week of building, and the screenshots were captured from an older iteration or designed in a graphics tool before the real UI existed. The reviewer opens the app, sees a home screen that does not match the first screenshot, and cites 2.3.3.
- Open your current build and put your screenshot set next to it, screen by screen. Every screenshot must show a screen that exists in the build you submitted, with the same layout and content style a user would actually see.
- Kill any screenshot that is pure marketing - a logo card, a quote, a feature promise with no interface in it. Text overlays and device frames around a real screen are fine; frames with no real app screen in them are what gets cited.
- Check the demo data in your screenshots. Placeholder text like lorem ipsum, obviously fake stats, or another product's name in the content reads as not-the-real-app to a reviewer.
- Confirm the screenshots match the platform. iPad slots need iPad captures of your actual iPad layout, not stretched iPhone images.
- Recapture from the shipping build, not from memory. If your UI is stable, capturing straight from the simulator against the release build guarantees the match.
Screenshots are also your listing's biggest conversion lever, so a 2.3.3 rejection is a decent excuse to redo them properly - [App Store screenshots that convert](/blog/app-store-screenshots-that-convert) covers the design side, and if you want the capture step to stop drifting out of date entirely, [automating screenshots with Claude Code](/blog/how-to-automate-app-store-screenshots-with-claude-code) makes the current build the only possible source.
Fixing 2.3.7: name, subtitle, and keywords
Clause 2.3.7 governs the metadata fields that feed search: the app name, the subtitle, and the keyword field. The app name is for your app's name - not a sentence of search terms. Stuffing descriptors into the name field, listing competitor or other brand names in your keywords, or putting claims like pricing or awards in the name are the classic citations. The temptation is obvious, because the name field is the strongest ranking surface in App Store search, and the guideline exists precisely because everyone is tempted.
- Name: your brand name plus at most a short natural descriptor. If the name reads like a keyword list instead of a name, cut it back.
- Subtitle: a plain-language line about what the app does. It ranks, so use real words your user would search, but keep it a sentence a human would say.
- Keyword field: single terms separated by commas, no repeats of words already in your name or subtitle, no other apps' brand names, no category words Apple already knows.
- Nothing in any of these fields should claim a ranking, a price, or a promotion - prices change and claims go stale, which is exactly the inaccuracy 2.3 is about.
The good news is that a 2.3.7 fix and good ASO are the same work: precise, honest fields built from terms real users search. The keyword research method in [how to find App Store keywords](/blog/how-to-find-app-store-keywords) produces fields that both rank and pass.
Fixing 2.3.1: when the app and the description disagree
Clause 2.3.1 cuts both directions. If your description promises features the app does not have, that is a 2.3.1 problem you fix by editing the description down to what actually shipped. If your app contains behavior the listing does not disclose - a mode that unlocks later, functionality that changes after review, anything the reviewer could not see or was not told about - that is the serious end of 2.3.1, and Apple treats hidden or switch-activated behavior as a trust violation, not a paperwork error. For a normal indie app the fix is honesty in the cheap direction: describe the app you shipped, not the roadmap.
While you are in the description, sweep for 2.3.10 in the same pass: references to your Android version, links that pitch other platforms, or in-app screens that mention platforms the app is not on. Keep the App Store listing about the iOS app.
Resubmitting: most 2.3 fixes do not need a new build
Because Guideline 2.3 is about the listing, the resubmission path is usually shorter than for a code rejection. When your app is in a rejected state, you can edit the metadata fields - screenshots, description, keywords, promotional text, release notes - and resubmit the same binary for review. You only need a new build when the fix is in the app itself, which for 2.3 means the hidden-or-undocumented-behavior end of 2.3.1. If your rejection was 2.3.3, 2.3.7, 2.3.10, or 2.3.12, fix the fields and resubmit; do not burn a build number on a listing problem.
- Fix exactly what the reviewer cited first, then sweep the related fields in the same clause so the next reviewer does not find the sibling mistake.
- If you believe the reviewer misread something - for example, a screenshot they thought was concept art is a real screen - reply in Resolution Center and explain where in the app that screen lives, the same way you would answer a Guideline 2.1 information request.
- Update your release notes if anything about the version's story changed. Blank or boilerplate what's-new text is its own citation under 2.3.12, and the update flow in [submitting an app update](/blog/how-to-submit-an-app-update-to-the-app-store) covers what good release notes look like.
- Resubmit and note what you changed, so if the same clause comes back you know the remaining gap is something else on the page.
Sweep your listing with Claude Code before you submit
The reason 2.3 rejections sting is that every one of them was catchable before submission with a boring cross-check nobody does under launch pressure: does each screenshot exist in the build, does the description only claim shipped features, is the keyword field clean. This is exactly the kind of tedious verification the Claude Code desktop app is good at. Point it at your project and your listing draft and have it do the comparison for you - it can read your app config and screens directly and check the listing against what is actually there.
- Paste your description in and ask it to list every feature claim, then check each claim against the screens and code that actually shipped. Anything it cannot find in the project gets rewritten or cut.
- Have it lint your name, subtitle, and keyword field against the 2.3.7 rules: no brand names that are not yours, no repeated terms across fields, no claims of price or rank.
- Ask it to enumerate the screens in your navigation and confirm every screenshot in your set corresponds to one of them.
- Run the sweep again on every update, not just the first submission - listings drift as the app evolves, and stale screenshots on version five are the same rejection as fake ones on version one.
Metadata is one section of the broader pre-flight in the [App Store submission checklist](/guides/app-store-submission-checklist), and the whole review-survival picture - 2.3 alongside the guidelines that actually judge your app - is in [how to pass Apple App Review](/blog/how-to-pass-apple-app-review).
Fix it once, with people who have eaten this rejection
Every clause in this post is something a member of App Store Launch Club has hit for real - the concept-art screenshot, the keyword-stuffed name, the description that promised the next version. Members post their listing before they submit and someone who has already taken the 2.3 round trip catches the mismatch in minutes. Join at applaunchclub.co for $9 a month and get your screenshots, name, keywords, and description sanity-checked against your actual build before App Review does it for you.
Short, practical drops on app ideas, validating fast, store listings, and passing app review. No spam, unsubscribe anytime.
Frequently asked questions
What is a Guideline 2.3 rejection?
Guideline 2.3 is Apple's Accurate Metadata rule in the Performance chapter of the App Review Guidelines. App Review cites it when your product page does not match your app - screenshots that do not show the real interface, a name or keyword field that stuffs terms or borrows other brands, a description that claims features the app does not have, or release notes that do not describe the update. The fix is almost always editing the listing to match the shipped app.
Do I need to upload a new build to fix a Guideline 2.3 rejection?
Usually not. Screenshots, description, keywords, name, subtitle, and release notes are all editable in App Store Connect while your submission is in a rejected state, and you can resubmit the same binary after fixing them. The exception is a 2.3.1 citation for behavior inside the app itself - hidden or undocumented functionality - which does require a changed build.
What does Guideline 2.3.3 mean by screenshots showing the app in use?
It means every screenshot must show a real screen from the build you submitted, as a user would see it. Text overlays and device frames around a real screen are fine. Pure marketing frames with no interface in them, concept art, mockups of unbuilt features, or captures from an older version that no longer matches the app are what get cited.
Can I put keywords in my app name?
A short natural descriptor next to your brand name is normal. A name field that reads as a list of search terms is what Guideline 2.3.7 targets, along with other apps' brand names anywhere in your metadata and claims like prices or rankings in the name. Put your search terms in the subtitle and the keyword field, where they belong and still rank.
Is a Guideline 2.3 rejection serious?
Most of the time it is the mildest rejection you can get - a listing edit and a resubmission of the same build. The serious end is 2.3.1 cited for concealed or misrepresented app behavior, which Apple treats as a trust issue. Fix listing-level citations promptly and honestly and they leave no lasting mark on your app or account.
Last reviewed by David on September 21, 2026
