The most common App Store rejections and how to avoid them

A rejection rarely means your app is bad. Usually it means the reviewer couldn't log in, a screenshot promised something the app doesn't do, or a purchase flow broke one of Apple's payment rules. Nearly all of these are predictable, and you can catch them before you submit.

This guide covers the guidelines behind most rejections, what reviewers actually check, and what to do when a rejection lands anyway, from replying in App Store Connect to filing an appeal. Guideline numbers refer to Apple's current App Review Guidelines. Apple updates them regularly, so check the live document for anything borderline.

Rejections by the numbers

Apple publishes an annual App Store Transparency Report. Its 2025 edition shows how often submissions fail:

Performance problems, which include crashes, incomplete apps and inaccurate metadata, account for most rejections by a wide margin. That is good news, because they are also the easiest to prevent.

Guideline 2.1: App Completeness

Apple wants to review the final version of your app. Rejections under 2.1 usually come from one of these:

• Crashes and obvious bugs on the device and OS version the reviewer uses. Test on a physical device running the latest public iOS, with a clean install, not just an upgrade over your dev build.
• Placeholder content such as "Lorem ipsum", empty tabs, "Coming soon" screens or test images.
• Broken links, especially your support URL and privacy policy URL. Both are required and must work.
• No way in. If the app needs a login, the reviewer needs working demo credentials, and your backend has to be live during review.
• In-app purchases that can't be found or don't work. Guideline 2.1(b) requires purchases to be complete, visible to the reviewer and functional. If a configured product can't be reached, explain why in the review notes.

Write review notes like a test script

The App Review Information section in App Store Connect is the most underrated tool you have. A reviewer who understands your app quickly is far less likely to misread it. Include:

• A demo account with sample data already in place, not an empty account that requires setup.
• Step-by-step paths to any feature that is gated, hidden behind hardware or location-dependent.
• What the app does in one or two sentences, especially if the category is unusual.
• For new features, a specific description (guideline 2.3.1 says generic notes can be rejected).
• Anything the reviewer needs from outside the app: hardware, a QR code to scan, a test card, or documentation for regulated features.

Guideline 2.3: Accurate Metadata

Your store listing is reviewed as strictly as your binary. Guideline 2.3 is about one idea: what the listing promises, the app must deliver. Common problems include:

Also check your age rating answers (2.3.6) and make sure screenshots and icons are appropriate for a 4+ audience, even if the app's own rating is higher (2.3.8). For writing metadata that is both compliant and keyword-rich, see how to write your app title and subtitle.

Guidelines 4.2 and 4.3: Minimum functionality and spam

These two are the frustrating ones for indie developers, because they judge whether your app is worth being on the store at all.

4.2 Minimum Functionality rejects apps that are basically a repackaged website, a list of links, a marketing brochure, or content that belongs in another store, such as books, songs or game guides. Apps also have to work on their own. 4.2.3 rejects apps that require installing another app to function. If you download large resources at first launch, show the size and ask the user first.

4.3 Spam covers two patterns. 4.3(a) rejects multiple bundle IDs for what is really one app, like one app per city or one per theme. Use a single app with in-app purchases or settings instead. 4.3(b) rejects apps in saturated categories that don't add anything new. Apple names dating, flashlight, sound effect, wallpaper, simple timer and fortune-telling apps as examples that need a meaningfully better or different experience.

• Lead with native capability. Widgets, offline use, notifications, Shortcuts, Live Activities, HealthKit, camera features: things a web page can't do.
• Make your difference visible. If your timer app is built for a niche such as language learners or kilns, show that in the first screenshots and the review notes.
• Don't ship templates. White-label apps from the same codebase submitted under different accounts are a classic 4.3 pattern.

Guideline 5.1.1 and privacy manifests

Privacy rejections fall under the Legal section, the second-largest group in Apple's report. The requirements in 5.1.1 are specific:

Two related rules trip people up. First, under guideline 4.8, if you offer a third-party or social login for the primary account, you generally also need an equivalent option that limits data to name and email and lets users keep their email private. Sign in with Apple meets this, and there are exemptions, for example when you only use your own company's account system. Second, purpose strings in Info.plist must explain why you need access in plain language. "This app needs your location" is weak. "Your location is used to show nearby trails" is clear.

Privacy manifests and required reason APIs

Apps and third-party SDKs declare their data practices in a privacy manifest file (PrivacyInfo.xcprivacy). If your app or its SDKs use certain APIs Apple classifies as "required reason APIs" (for example UserDefaults, file timestamps, system boot time and disk space), the manifest has to declare an approved reason code for each one. Uploads with missing declarations get flagged by App Store Connect during processing, before a human reviewer ever sees the build. Apple also maintains a list of commonly used third-party SDKs that must ship their own manifest and signature, so keep those dependencies up to date.

Guideline 3.1: In-app purchase and subscriptions

Business-section rejections mostly concern how you charge. The core of 3.1.1: if you unlock digital features or content inside the app, use In-App Purchase. That covers subscriptions, premium features, in-game currency and full versions. License keys, QR codes and similar workarounds for unlocking are not allowed.

• Provide a Restore Purchases option for restorable purchases.
• Explain the subscription before asking for it (3.1.2). Show what the user gets, the price and the billing period clearly. Hiding the price or the renewal terms behind small print is a common rejection, and so is a missing link to your Terms of Use (EULA) and privacy policy on the paywall.
• Subscriptions need ongoing value and a period of at least seven days.
• Know the exceptions. Reader apps, person-to-person services, physical goods and enterprise apps have their own rules under 3.1.3. On the US storefront, the current guidelines allow buttons and links to purchase outside the app. Other storefronts have different rules and entitlements, so check the guideline text for each region you sell in.

Guideline 2.5: Software requirements

These are the technical rules, and they are usually discovered by automated checks or the reviewer's device:

• 2.5.1 requires public APIs only, used for their intended purpose, on the current OS. Remove deprecated frameworks and leftover private-API calls in old dependencies.
• 2.5.2 requires the app to be self-contained. You can't download or execute code that adds or changes features after review (there is a narrow exception for educational coding apps).
• 2.5.4 limits background modes to their intended purposes, such as audio, VoIP, location and task completion. Declaring background audio just to keep the app alive is a frequent rejection.
• 2.5.14 requires explicit consent and a clear indicator when you record the screen, camera, microphone or user activity.

What happens after you press Submit

How to reply to a rejection and when to appeal

The rejection message appears on the App Review page for your app in App Store Connect. Many developers still call this the Resolution Center. It cites the guidelines involved and often includes screenshots of what the reviewer saw. Stay calm, and treat it as a conversation.

1. Read the cited guideline in fullRead the current text, not your memory of it. Often the fix is narrower than it first seems.
2. Reproduce what the reviewer sawUse a clean install, the same device class and the latest iOS. Many 2.1 rejections come down to a server state or a login that only fails for new users.
3. Fix it, or explain itIf it's a misunderstanding, reply in App Store Connect with specific, polite steps, for example: "The feature is in Settings → Sync. Use the demo account below, which has sample data." Attach a short screen recording if it helps.
4. Resubmit with updated notesMention what changed. If only metadata was wrong, you can often fix it without uploading a new build.
5. Appeal only when you are confidentIf you believe the reviewer misunderstood your app or treated it unfairly, you can submit an appeal to the App Review Board. Apple asks for specific reasons why the app complies, one appeal per rejected submission, and answers to any open information requests first.

Pre-submit checklist

• Clean install tested on a physical device with the latest iOS, with no crashes and no placeholder content
• Demo account with sample data in App Review Information, and the backend is live
• Support URL and privacy policy URL both load, and the privacy policy is also linked in the app
• Account deletion available in the app if users can create accounts
• Paywall shows price, period, what's included, and Terms and Privacy links; Restore Purchases works
• All in-app purchases submitted and reachable by the reviewer
• Screenshots show the real app; no competitor names or prices in metadata
• Privacy manifest covers required reason APIs; SDKs up to date; App Privacy answers match
• Purpose strings explain why each permission is needed, and the app works if one is declined

Rejections are part of shipping on the App Store, and a clean submission is the best way to keep them rare. When your build is ready, pair this list with the ASO launch checklist so the listing is ready too, and run your current page through the free ASO score tool.

Frequently asked questions