Getting a “Rejected” email from App Store Connect is every iOS developer’s least favourite moment. Three more days of waiting, launch plans slip, the client starts asking questions. I’ve shipped 40+ submissions across 12 apps, and been rejected more than once. Below are the reasons I hit most often, and how to head them off.
1. Guideline 5.1.1, Privacy, Data Collection and Storage
The rule Apple enforces hardest. If your app collects user data:
- Fill out Privacy → App Privacy in App Store Connect accurately and completely
- Ship a Privacy Manifest (PrivacyInfo.xcprivacy), required since iOS 17
- Add the manifest entries for every third-party SDK (Firebase, Facebook, analytics)
- If you use a crash reporter, declare “Crash Data” collection
The most common mistake: you add a third-party analytics SDK but forget to declare its collection in the manifest. Review catches it and rejects.
Fix: update the App Privacy page every time you add an SDK. Xcode 15’s Privacy Report feature flags what’s missing at build time.
2. Guideline 4.0, Design, login requirements
“Core functionality of your app cannot be tested without an account” is a rejection I’ve seen plenty. Apple’s rule is clear:
If you require login, you have to do one of:
– Offer Sign in with Apple (required if you offer social login)
– Expose the core features without an account (demo mode, guest mode)
– Put test credentials in Review Notes
I always put test account credentials, login flow, and step-by-step access to the critical features in Review Notes. The more specific you are, the less risk.
3. Guideline 2.1, Performance, Crashes
If the app crashes during review, forget rejection, even a single crash triggers an “extra scrutiny” pass on your app.
If crash-free sessions in TestFlight are below 99.5%, I don’t submit. Before every submission:
- Run Xcode Instruments → Allocations, Leaks
- Push a build to TestFlight, at least two external testers for a week
- Check the Crashes tab in App Store Connect, I want zero
- Don’t list known bugs in TestFlight notes, a reviewer will go try to reproduce them
4. Guideline 3.1.1, In-App Purchase
If your app sells digital content or features, you must use IAP. Try to take payment via Stripe or PayPal and it’s an instant reject.
Some fine points to watch:
- A “Restore Purchases” button has to be visible at all times (Settings or Profile)
- When loading premium content, don’t just say “Premium content”, tell the user what they’re getting
- Terms of subscription and privacy policy have to be reachable from inside the app
5. Guideline 2.3.10, Accurate Metadata
Your App Store metadata (screenshots, description, keywords) can’t be misleading:
- Screenshots have to show the actual app UI, mockups or renders are not accepted
- Don’t make comparisons in the description (“number one in publishing”)
- Don’t mention other app names (“alternative to Spotify”)
- Don’t stuff competitor brand names into keywords
Once I wrote “for WordPress” in an app description and got rejected, because WordPress is a registered trademark and needs permission.
6. Guideline 4.3, Spam / Design Duplication
Apple watches this closely: one developer with many similar apps looks like spam.
I ship 12 apps but they’re each completely different: horse racing game, dental tracking, sleep sounds, CV builder. Themes and target audiences diverge. If I’d shipped three meditation apps, one of them would almost certainly get a 4.3 rejection.
Fix: if you’re shipping similar apps, either publish them under separate developer accounts or group them under a distinct brand.
7. Take Review Notes seriously
Most developers skip Review Notes. I always write:
- Test account credentials (no 2FA)
- Step-by-step flow for the three most important features
- If the app talks to a backend: which server the API is on, whether there’s a rate limit
- If you use location, camera, or notifications: the use case
- A list of third-party SDKs in use
The reviewer reads these and uses them during testing. The more detail you give, the smoother the review.
8. Submission timing strategy
Don’t submit on a Friday. The review team works weekends, but if you get a rejection on Saturday or Sunday you can’t do anything until Monday.
My approach: submit Tuesday or Wednesday. The verdict lands by Thursday. If it’s rejected I fix and resubmit Friday, second review hits Monday or Tuesday.
9. What to do when you are rejected
Don’t panic:
- Read the rejection message carefully, which guideline is Apple citing?
- Open the guideline page and read it, there’s usually an example
- You can reply through Resolution Center, and if the reviewer misread your app, state your case
- Fix, resubmit
Reviewers sometimes make mistakes. Even when the call is wrong, asking politely “could you take another look at this section” gets a response most of the time.
Takeaway
App Store review isn’t rocket science, but it’s a discipline. I run my own checklist before every submission. Hit these items and there’s a 95% chance you pass on the first try.