Nothing deflates a launch like the email that starts “Hello, Thank you for your submission…” Every experienced indie developer has a rejection story, and the striking thing is how repetitive the stories are. First-timers rarely fail on exotic grounds — they hit the same dozen walls. Here they are, with the guideline numbers you’ll see in the rejection, so you can avoid every one of them.
1. It crashes on first launch (Guideline 2.1)
The most common rejection is also the most avoidable. Reviewers test on devices and OS versions you didn’t. Test on a freshly wiped device or simulator, and re-test on the release build — the one produced by Archive, not the debug build from Xcode’s run button. Debug builds hide crashes that release builds surface.
2. Placeholder content anywhere (Guideline 2.1)
Lorem ipsum text, “coming soon” tabs, empty settings pages. If a screen isn’t finished, cut it from this build. Reviewers tap everything.
3. Shipping what is obviously a beta (Guideline 2.1)
If your app is unfinished, that’s what TestFlight is for. Labels like “beta” or “v0.1” in the UI read as an admission that the build isn’t ready for the store.
4. Screenshots that show a different app (Guideline 2.3.1)
Marketing screenshots must show your actual interface. Pretend features, fake data-heavy dashboards, or screenshots taken from a competitor will get you rejected — and repeated attempts get you flagged.
5. A paywall the reviewer can’t test (Guideline 2.1)
If your app requires an account, provide a demo login in the App Review notes. If parts of the app are behind your paywall, give the reviewer a sandbox or free unlock. A reviewer who can’t reach your features assumes the worst.
6. Selling digital goods outside IAP (Guideline 3.1.1)
Digital features and content must use Apple’s in-app purchase. Mentioning external payment for digital goods in the app is a fast rejection. Physical goods and services are a different story, but digital is Apple’s turf — plan for the 15–30% cut in your pricing from day one.
7. No privacy policy, or a dead link (Guideline 5.1.1)
Every app needs a reachable privacy policy URL — including apps that collect nothing (“this app collects no data” still needs to be stated). Host it on your own site, not a Google Doc.
8. Collecting data without a clear reason (Guideline 5.1)
Ask for location, contacts, camera, or tracking only where the feature obviously needs it, and explain why in the permission prompt. Requesting every permission upfront is a pattern reviewers recognize instantly.
9. A web page in an app costume (Guideline 4.2)
If your app is a thin wrapper around a website, expect a rejection for minimum functionality. Native navigation, offline behavior, and system integration (widgets, share sheet, push) are what separate an app from a bookmark.
10. Keyword-stuffed names (Guideline 2.3.7)
“Photo Editor: Filters, Collage, Camera FX, Pics Art Pro” — no. The app name has limits for a reason. Subtitles and keyword fields exist for search terms; the name is the name.
11. Empty or dishonest metadata (Guideline 2.3)
Description, keywords, and category must match what the app does. Unsupported hardware claims (“works on Apple Watch” when it doesn’t) are checked.
12. Fighting the reviewer instead of the rejection
When you are rejected, the reply box is a negotiation, not a rant. Restate what the reviewer did, explain the misunderstanding precisely, attach a build number, and use screenshots. Politeness plus specifics resolves the majority of disputes. If you’re genuinely right, an appeal exists — but you’ll rarely need it if your case is concrete.
The pre-flight checklist
- Archive build tested on a clean device and one older OS version
- Every screen free of placeholder or unfinished content
- Demo account + review notes explaining anything gated
- Privacy policy live on your own domain
- Permission prompts with real explanation strings, requested in context
- Screenshots showing the real UI, correct device sizes
- Name and keywords clean of stuffing
Rejection isn’t failure — it’s a code review from a stranger with authority. Treat it that way and most reviews take one pass. The deeper context for all of this is in my piece on what shipping alone is really like, and if you’re still deciding how to charge, start with the pricing decision.