Common App Store Rejection Reasons (and How to Fix Each One)

Quick answer: Most App Store rejections come from a short list: crashes, placeholder content or a missing demo account (guideline 2.1); screenshots and metadata that don't match the app (2.3); privacy problems such as a missing policy, vague permission prompts or no account deletion (5.1.1); digital goods sold without in-app purchase (3.1.1); and thin or duplicate apps (4.2, 4.3). Fix the issue, reply in App Store Connect, and resubmit.

Apple publishes its own list of common issues on its App Review page and says that, on average, over 40% of unresolved issues relate to guideline 2.1, App Completeness. Here's how the frequent ones map to guidelines and fixes:

Read the rejection message closely. App Review quotes the guideline number and usually describes what they saw, sometimes with a screenshot. That tells you whether you need a new build or only a metadata change.

Guideline 2.1 asks for final versions with all necessary metadata and fully functional URLs, and it explicitly calls for demo account information (with your backend switched on) if the app has a login. Typical triggers:

• A crash on launch on the iOS version or device the reviewer used. Reviewers may run your iPhone app on an iPad, so test it there too.
• A login wall with no credentials, expired demo passwords, or two-factor codes sent to your own phone.
• Placeholder content such as lorem ipsum, "coming soon" tabs, or test data.
• In-app purchases that don't load because the products weren't submitted or the Paid Apps Agreement isn't active.
• Features the description promises that reviewers can't find.

Fix: reproduce the issue, ship a new build, and use the App Review notes to explain where everything lives. For hardware-dependent or region-locked features, attach a short video.

Guideline 2.3 requires your description, screenshots, previews and privacy information to accurately reflect the app's core experience. Frequent problems:

• Screenshots that show only a splash screen, title art or a login page (2.3.3).
• Mockups of features that aren't in the submitted build.
• Android devices, Google Play badges or other platform names (2.3.10).
• Real people's personal data instead of fictional accounts (2.3.9).
• Premium features shown without indicating they require a purchase (2.3.2).
• Keyword stuffing, competitor names or pricing words in the name or keywords (2.3.7).
• Generic What's New text or review notes for an update (2.3.1(a), 2.3.12).

These often result in a Metadata Rejected status, which you can fix without a new build. The full playbook is in App Store metadata rejected, and App Store screenshot guidelines explains each screenshot rule.

Privacy rejections are common because they span the build, the metadata and your website.

• Privacy policy: guideline 5.1.1(i) requires a link in App Store Connect and an easy-to-find link inside the app. Apple's common-issues list adds that the policy should identify what data you collect, how, and how users can request deletion.
• Permission prompts: purpose strings such as NSCameraUsageDescription must clearly and completely explain how the app uses the data. "This app needs camera access" is too vague; "Scan receipts to add expenses automatically" is specific.
• Account deletion: guideline 5.1.1(v) says that if your app supports account creation, it must also offer account deletion within the app.
• Tracking: if you track users across other companies' apps or websites, you need App Tracking Transparency permission first.
• Privacy details: your App Privacy answers must match what the app and its SDKs actually collect. See privacy labels.

Guideline 3.1.1 says that if you unlock features or functionality inside the app, such as subscriptions, in-game currencies, levels, premium content or a full version, you must use in-app purchase. Physical goods and services consumed outside the app follow different rules.

Common triggers:

• A "Go Pro" button that opens a web checkout for digital features.
• License keys or promo codes that unlock content without going through Apple's mechanisms.
• A subscription screen that doesn't clearly state price, duration and what's included.
• No way to restore purchases on a new device.

Rules on linking to external purchases differ by storefront and have changed in recent years, so read the current text of guidelines 3.1.1 and 3.1.3 for the regions you sell in.

• 4.2 Minimum Functionality: your app should offer features, content and UI that elevate it beyond a repackaged website. A WebView wrapper with no native value is the classic case.
• 4.3 Spam: don't submit multiple bundle IDs of the same app, such as one app per city or per theme. Combine them and use in-app purchase or content options instead. Apple also rejects copycats of other apps.
• 4.8 Login Services: if you use a third-party or social login for the user's primary account, you must also offer an equivalent login option with the privacy features the guideline lists.
• 2.5.1 Software Requirements: apps may only use public APIs and must run on the currently shipping OS.

1. Open the submission. In App Store Connect, open the app, click the link about unresolved issues, then Resolve next to the submission.
2. Ask if it's unclear. Click Reply to App Review, describe what you need clarified, and attach screenshots or documents.
3. Fix the right layer. Binary issues need a new build with a higher build number. Metadata issues only need edits; you can resubmit the same build.
4. Explain what changed. In your reply and in the review notes, list each fix and where reviewers can verify it.
5. Resubmit. Avoid unrelated changes so the next review is focused.

If you're shipping a bug-fix update and App Review finds unrelated older issues, Apple may let you address them in your next submission, as long as there are no legal or safety concerns. Accept that offer by replying to the message.

If you believe the reviewer misunderstood your app, you can appeal to the App Review Board. Give specific reasons your app complies, answer any open questions first, and submit only one appeal per rejected submission.