App Store Guideline 2.3 Rejection: Fix Misleading Metadata

What guideline 2.3 "Accurate Metadata" actually says

Apple's rule is short: customers should know what they're getting. Your metadata has to "accurately reflect the app's core experience" and stay up to date with each new version. Apple splits the rule into 13 sub-guidelines, from 2.3.1 to 2.3.13. Your rejection message names one of them. That number tells you where to look. In this rule, metadata means:

• App name, subtitle and keywords
• Description and "What's New" text
• Screenshots and app previews (videos)
• Category and age rating
• Privacy information (the privacy labels)
• Notes for Review
• In-app purchase names, screenshots and descriptions

Guideline 2.3 rejection decoder: what Apple saw and how to fix it

Here are the sub-guidelines that show up most on first submissions. The rules come straight from Apple's App Review Guidelines.

• 2.3.1(a) Hidden or misleading features. What the reviewer saw: a feature in the listing that isn't in the app, or vague Notes for Review. The fix: remove the claim, or ship the feature. Describe new features specifically in Notes for Review. New build needed: only if you ship the missing feature.
• 2.3.2 In-app purchases. What the reviewer saw: paid content shown as if it were free. The fix: say clearly in the description and screenshots which items need a purchase. New build needed: usually no.
• 2.3.3 Screenshots. What the reviewer saw: splash screens, login pages or marketing art instead of the app in use. The fix: replace them so more than half show real app screens. New build needed: no.
• 2.3.4 Previews. What the reviewer saw: a video with mockups, renders or footage from outside the app. The fix: use only screen recordings of the app, with narration or text overlays if needed. New build needed: no.
• 2.3.6 Age rating. What the reviewer saw: answers to the age rating questions that don't match the content. The fix: answer them again honestly. New build needed: no.
• 2.3.7 Name and keywords. What the reviewer saw: competitor names, trademarks, prices or keyword stuffing, or a name over 30 characters. The fix: pick a unique name, remove other brands and prices, keep keywords accurate. New build needed: no.
• 2.3.8 All audiences. What the reviewer saw: icons or screenshots unsuitable for a 4+ audience, or "For Kids" outside the Kids category. The fix: swap the images, remove the reserved words. New build needed: only if the icon is in the binary.
• 2.3.9 Rights and real data. What the reviewer saw: a real person's name, email or photo in screenshots, or images you don't own. The fix: use made-up demo accounts and licensed images. New build needed: no.
• 2.3.10 Other platforms. What the reviewer saw: Android, Google Play or another marketplace mentioned or shown. The fix: remove every mention and every Android-style screen. New build needed: only if it appears inside the app.
• 2.3.12 What's New. What the reviewer saw: a generic "bug fixes" note on an update with big changes. The fix: list the real changes. New build needed: no.

When you only need to edit App Store Connect

When the problem is only in the listing, you fix it in App Store Connect and send it back. Screenshots, description and keywords are edited in App Store Connect, no new build needed. Keep your build as it is and only touch what Apple flagged.

Guideline 2.3.3 rejection: the screenshot problem

This is the most common 2.3 case on a first launch. Apple's own reference page sets the rule: App Review approves only submissions where more than half of the screenshots for each device show the app in use. With 3 screenshots, 2 must be real app screens. With 4, 3 must be. What gets rejected:

• A first screenshot that is just the logo or the splash screen
• A login or sign-up screen as one of only a few images
• A tiny phone mockup behind a big marketing headline
• Screens designed in Figma that don't match the shipped interface
• Old screenshots from a previous version

How to fix your screenshots

One detail catches teams with a translated listing. If you localize the description, localize the screenshots too. A French description next to English-only screenshots can be read as an inaccurate listing. Follow these steps:

• 1. Install the exact build you submitted on a real device or simulator.
• 2. Log in with a demo account filled with realistic, fictional data.
• 3. Capture your core flow: the main screen, the key action, the result.
• 4. Add a short caption above each screen if you want. Keep the app clearly visible.
• 5. Repeat for every device size you support. iPad screenshots count separately if you ship for iPad.

Guideline 2.3.1 rejection: when the listing promises more than the app

A 2.3.1(a) rejection is more serious. Apple says marketing an app in a misleading way, by promoting content or services it doesn't offer or a false price, can lead to removal and even termination of the developer account. Repeated or egregious cases can get you removed from the Apple Developer Program. In practice, on a first submission, it usually comes from one of these:

• The description lists the roadmap. "AI coach, community, wearables sync" when only the first one works today.
• Features behind a login the reviewer can't reach. If Apple can't get in, the feature doesn't exist for them. Add working demo credentials in App Review Information.
• Vague Notes for Review. Apple writes that generic descriptions will be rejected. Say what the app does, where each feature is and how to test it.
• A web wrapper sold as a native app. Developers on Apple's forums report 2.3.1(a) arriving together with guideline 4.2 (minimum functionality) when the listing promises more than a thin wrapper delivers.

How to fix a 2.3.1 rejection

Cut the description down to what the reviewer can tap today. Your roadmap belongs in your pitch deck, not your App Store page. If the app really is too thin, the problem isn't the metadata, it's the product. That's a build job, and we cover it in our guides on Lovable and AI builders. Rejected twice and not sure if it's the listing or the app? Book a call and we'll read your rejection message with you.

Mistakes we see in cross-platform and AI-built apps

Apps built with Expo, React Native, Flutter or an AI builder hit 2.3 for reasons the general rejection lists don't cover:

• Android screenshots reused for iOS. An Android status bar or back button is enough to trigger 2.3.10.
• "Also on Google Play" in the description. Same rule. Keep the iOS listing about iOS.
• Placeholder text left in the app. "Lorem ipsum" or template names visible in screenshots show the listing doesn't reflect a finished app.
• Privacy labels copied from a template. If your app uses analytics, crash reporting or a login SDK, the privacy details must say so. The 2.3 intro lists privacy information as metadata.
• The founder's real account in screenshots. Your name, email and photo break 2.3.9. Create a demo user.
• An icon that differs between the app and the store. 2.3.8 asks for consistent icons to avoid confusion.

How to fix a guideline 2.3 rejection and resubmit

If you've hit other rejections too, our mobile app building guides cover the other problems founders run into before launch. Work through these steps:

• 1. Read the full message in App Store Connect. Note the sub-number and any screenshot Apple attached.
• 2. Check if Apple let you fix it later. Some 2.3 messages say the issue can be resolved in your next update. On Apple's forums, one developer replied as asked, then resubmitted anyway and was rejected again. If the message says you don't need to resubmit, reply and wait.
• 3. Fix every 2.3 issue at once, not only the one cited. Run through the decoder list above before you send.
• 4. Reply in Resolution Center. Explain briefly what you changed. If you think the reviewer got it wrong, explain why, with steps to see the feature.
• 5. Resubmit. Metadata only: edit and send. Feature missing: ship the feature or cut the claim.

When to bring in a developer

A 2.3 rejection about screenshots or keywords is usually something you can fix yourself in App Store Connect. Get help when:

• Apple pairs 2.3.1 with 4.2 or 2.1, which means the app itself is the problem
• The feature the listing promises doesn't work in the build
• You can't produce real screenshots because the app crashes or the core flow is broken

How BuildMVPFast gets a blocked app to launch

That's where our MVP Development service or our AI prototype to production service comes in. For AI-built apps, that means an AI-generated code audit (punch list), a harden vs rebuild recommendation and the App Store path when you actually need it. For mobile builds, it includes TestFlight + Play submission support. In both cases, you keep the GitHub. Want a clear read of what's blocking your launch? Book a call and bring your rejection message.

What does guideline 2.3 mean on the App Store?

Guideline 2.3 is "Accurate Metadata." Apple rejects an app under it when the name, description, screenshots, previews, age rating, privacy details or review notes don't match what the app actually does.

Do I need a new build to fix a 2.3 rejection?

Usually not. Screenshots, description, keywords, age rating and privacy labels are edited in App Store Connect. You only need a new build if the app is missing a feature the listing promises, or if the problem (an icon, an Android reference) is inside the app.

How many screenshots must show the app in use?

More than half, for each device type. Apple's reference for 2.3.3 gives the example: 2 out of 3, or 3 out of 4.

Can I mention my Android app in the App Store description?

No. Guideline 2.3.10 bans names, icons or images of other mobile platforms or app marketplaces in your metadata, unless there is specific, approved interactive functionality.