Most App Store rejections come from a short list of causes, and almost all of them are avoidable before you ever hit submit. The big ones: the app crashes or has placeholder content (Guideline 2.1), it collects data without the right privacy declarations, its metadata does not match what the app does, it takes payment for digital goods outside In-App Purchase, or it offers third-party login without Sign in with Apple. Fix those ahead of time and most apps clear review on the first try. Get rejected anyway, and the fix is usually specific and quick once you read the guideline Apple cited.
This guide walks the rejection reasons that actually catch indie developers, in the order they matter, plus what to do when a rejection lands in your Resolution Center. It is written to get you through review, not to relitigate whether Apple's rules are fair.
On this page
- The reasons that catch most people
- Privacy is where modern apps get caught
- In-App Purchase and subscription rules
- Sign in with Apple parity
- Test before you submit
- What to do if you get rejected
- FAQ
The reasons that catch most people
The single most common rejection is Guideline 2.1, App Completeness, and it is almost always something you could have caught yourself.
- Crashes and bugs. The app crashed or misbehaved on the reviewer's device. Reviewers test on current hardware and OS; a crash they hit is an instant rejection.
- Placeholder content. Lorem ipsum, empty states with no data, "coming soon" screens, or broken images. If a screen is not finished, do not ship it.
- Broken links. A privacy policy link that 404s, a support URL that goes nowhere, a button that does nothing. Reviewers click things.
- No demo account. If your app requires login, you must provide working demo credentials in App Review notes, or the reviewer cannot see the app and rejects it.
Two neighbors of 2.1 also bite. Guideline 4.2, Minimum Functionality, rejects apps that are too thin, a bare web wrapper or something that does almost nothing native. Guideline 4.3, Spam, rejects copycats and apps spun from a template with no unique value of their own. The fix for both is the same: ship something that genuinely does a useful thing, natively.
Privacy is where modern apps get caught
Privacy has become the most common reason a technically-working app still gets rejected, because the requirements grew and are easy to miss.
- Usage-description strings. Every sensitive capability you touch, camera, photos, location, microphone, contacts, needs a purpose string in Info.plist (
NSCameraUsageDescriptionand friends) explaining why. Access the API without one and the app crashes or is rejected; write a vague string and it can still be rejected. - The privacy manifest. Apple requires a
PrivacyInfo.xcprivacyfile that declares the data your app collects and your reasons for using certain "required reason" APIs (likeUserDefaultsand file timestamps). Several common SDKs need one too. A missing or incomplete manifest is a modern, frequent rejection. - App Tracking Transparency. If you or an SDK you bundle tracks users across other apps and websites, you must show the ATT prompt and include
NSUserTrackingUsageDescription. Tracking without the prompt is a hard rejection, and reviewers check. - Data disclosure accuracy. The privacy "nutrition label" you fill in on App Store Connect has to match what the app actually collects. Overclaiming or underclaiming both cause problems.
The theme is that privacy is now a build-time concern, not an afterthought. Get the strings, the manifest, and the ATT prompt in before you submit.
In-App Purchase and subscription rules
If you sell anything digital, Guideline 3.1.1 is strict: digital goods and services must be sold through In-App Purchase. You cannot send users to an external website to pay, or even hint at cheaper prices elsewhere, unless you are explicitly using one of the regional entitlements Apple has introduced (the EU alternative terms, and the US external-link entitlement), which carry their own rules and disclosures. If you are not using those on purpose, use IAP and do not link out.
For subscriptions, Guideline 3.1.2 requires your paywall to be honest and complete: it must state what the user is buying, the price and billing period, that it auto-renews, and how to cancel, and it must link to your Terms of Use and Privacy Policy. A paywall missing the auto-renew disclosure or the terms links is a routine rejection, and it is entirely mechanical to get right.
Sign in with Apple parity
This one surprises people. Under Guideline 4.8, if your app offers any third-party or social login, Google, Facebook, and so on, as its only or primary sign-in options, you generally must also offer Sign in with Apple as an equivalent option. Ship Google sign-in alone and you can be rejected for not offering the Apple equivalent.
The fix is to add Sign in with Apple alongside your other providers. It is a small amount of code, and having it there removes a rejection category entirely.
Test before you submit
Most 2.1 rejections die in a fifteen-minute pre-submit pass.
- Run it on a real device, not just the simulator, on a current OS version. Reviewers use real hardware.
- Walk every flow as a new user, including the empty states and the first-launch experience, and click every link.
- Ship a TestFlight build first. Beta testers surface the crash on a device you do not own before the reviewer does.
- Fill in the App Review notes, with demo credentials if login is required and any context the reviewer needs to reach your features.
None of this is glamorous, and all of it is cheaper than a rejection and a re-review wait.
What to do if you get rejected
A rejection is not a verdict, it is a specific note. Handle it methodically.
- Read the exact guideline number Apple cites in Resolution Center. The rejection tells you precisely which rule and often includes a screenshot. Do not guess.
- Fix the specific thing, then reply in Resolution Center explaining what you changed, and resubmit. Most rejections resolve in one round.
- Ask for clarification in Resolution Center if the reason is genuinely unclear, rather than resubmitting blindly and burning another review cycle.
- Appeal only when you are actually right. If you believe the rejection is a mistake, there is an appeals process, but use it for real errors, not to argue a rule you do not like. Fixing is almost always faster than arguing.
The developers who ship smoothly are not the ones who never get rejected; they are the ones who read the citation, fix the one thing, and resubmit the same day.
FAQ
What is the most common reason for App Store rejection?
Guideline 2.1, App Completeness: crashes, placeholder content, broken links, or a login-required app submitted without demo credentials. It is also the most avoidable, since a short pre-submit pass on a real device catches most of it.
Why do apps get rejected for privacy?
Usually a missing usage-description string, a missing or incomplete PrivacyInfo.xcprivacy privacy manifest, tracking users without showing the App Tracking Transparency prompt, or a privacy nutrition label that does not match what the app collects. Privacy is now a build-time requirement, not an afterthought.
Can I sell digital goods without In-App Purchase?
Generally no. Guideline 3.1.1 requires digital goods and services to use In-App Purchase, and you cannot steer users to external payment unless you are explicitly using a regional entitlement (EU alternative terms or the US external-link entitlement) with its own rules. If you are not, use IAP.
Do I have to offer Sign in with Apple?
If your app offers third-party or social logins like Google or Facebook as its main sign-in method, then generally yes, Guideline 4.8 requires you to also offer Sign in with Apple as an equivalent option. Adding it removes that rejection category.
What should my subscription paywall include to pass review?
Guideline 3.1.2 requires the paywall to state what is being purchased, the price and billing period, that it auto-renews, and how to cancel, plus links to your Terms of Use and Privacy Policy. It is mechanical to get right and a common cause of rejection when missing.
What do I do after my app is rejected?
Read the exact guideline number in Resolution Center, fix that specific issue, reply explaining what you changed, and resubmit. Most rejections clear in a single round. Ask for clarification if it is unclear, and appeal only if the rejection is a genuine error.
Spaceport generates iOS projects built to clear review the first time. The privacy manifest, the App Tracking Transparency and usage strings, Sign in with Apple alongside Google, and a subscription paywall with the Guideline 3.1.2 disclosures and Terms and Privacy links are all wired in from the first build, so the compliance work that causes most rejections is already done. And before launch, you need users: Lighthouse is the sibling toolkit for the waitlist and newsletter that get you your first hundred. From an indie iOS dev, for indie iOS devs.