App Store rejections: the 9 most common reasons and how to avoid them

A rejection is not the end of the world, but it costs days you would rather spend launching. The good news: almost every rejection comes from a short list of guidelines, and almost all of them can be caught before you press submit.

#1. Guideline 2.1: App Completeness

The most common one. The reviewer hit a crash, a broken link, placeholder text or a feature they could not reach.

• Test the exact build you submit on a real device, not only in the simulator
• Remove "coming soon" screens and lorem ipsum
• If the app needs an account, give Apple a working demo account in the review notes
• If features depend on hardware, a location or a backend switch, explain how to reach them

#2. Guideline 2.3: Accurate Metadata

Screenshots, descriptions and previews must show the actual app. Mock-ups of features that do not exist yet, prices in screenshots or mentions of other platforms get flagged.

#3. Guideline 4.2: Minimum Functionality

Apps that are a website in a wrapper, or offer too little to be useful, are rejected. Native navigation, offline states, push notifications or platform features like widgets show Apple the app adds real value.

#4. Guideline 4.3: Spam

Publishing many near-identical apps, or an app that copies a crowded category without anything new, falls here. One good app with options beats five clones.

#5. Guideline 3.1.1: In-App Purchase

Digital content and features unlocked inside the app must be sold through Apple's In-App Purchase. Physical goods and real-world services are the exception. Your paywall also needs a visible restore button and clear subscription terms. Our StoreKit 2 guide shows the client side.

#6. Guideline 5.1.1: Data collection and storage

Privacy is where many first submissions stumble:

• A privacy policy link in App Store Connect and inside the app
• Permission prompts with clear purpose strings that say why you need access
• Only ask for data the feature actually needs
• Account deletion: if users can create an account, they must be able to delete it from inside the app

#7. Privacy manifests and required reasons

Apps and their third-party SDKs must declare why they use certain system APIs, such as reading file timestamps or user defaults, in a privacy manifest. Keep your SDKs up to date; most popular ones now ship their own manifest.

#8. Guideline 4.8: Login Services

If you offer sign-in with a third-party social account, Apple requires an equivalent privacy-focused option. Sign in with Apple is the simplest way to meet it.

#9. Guideline 2.5: Software Requirements

Using private APIs, downloading executable code or building with an outdated SDK leads to rejection. Apple raises the minimum SDK every spring, so build with the current Xcode before you submit.

#Our pre-submission checklist

1. Fresh install of the release build on a real iPhone, every main flow tested
2. Demo account and step-by-step notes in App Review Information
3. Screenshots taken from the real app, no other platforms mentioned
4. Privacy policy and support URLs that load
5. Privacy nutrition labels match what the app and its SDKs collect
6. Paywall shows price, period, terms and a restore button
7. Account deletion reachable from settings
8. Purpose strings for every permission, in every language you ship

#If you are rejected anyway

Read the message carefully; it cites the guideline and often a screenshot. Fix the issue, reply in Resolution Center if something needs explaining, and resubmit. If you believe the reviewer is wrong, you can appeal to the App Review Board.

When we launch apps for clients, we handle the listing, the review notes and any back-and-forth with Apple. See how long a full launch usually takes.