Quick summary
An App Store rejection is rarely a judgement on your app's quality — it is usually about procedural details best handled before submission. What we actually hit shipping our own apps: forcing sign-in before showing any content (guideline 5.1.1), missing content reporting and user blocking in apps where people post (guideline 1.2), no in-app account deletion, and weak permission justifications. There is a second category unrelated to human review: automated upload errors such as ITMS-90683, rejected within minutes.
1) Forcing sign-in before anything — guideline 5.1.1
The most common rejection we have seen, and the easiest to avoid. The rule: if your app can show something useful without an account, it must. An account is requested only when reaching a feature that belongs to the user — a booking, an order, a saved item, a conversation.
Our fix is a guest mode: the user browses real content with no account, and tapping something identity-bound shows a courteous card explaining why sign-in is needed now. The benefit is double — you pass review, and you keep users who would have left at an empty login screen.
2) User-generated content with no reporting or blocking — guideline 1.2
If any user can post a listing, comment or photo, this guideline applies and asks for four things together: a way to report offensive content, a way to block a specific user, a mechanism to remove reported content within a reasonable time, and terms the poster agrees to.
The common mistake is assuming "the admin dashboard can delete it" suffices. It does not — per-user blocking is specifically required: an admin ban hides a poster from everyone, a user block hides them from one person. Neither replaces the other, and we learned that distinction the hard way.
3) In-app account deletion
If your app creates accounts, it must let the user delete theirs inside the app, not by emailing support. Put it in the account screen, make it actually delete rather than merely deactivate, and tell the user what is removed and what is retained for legal reasons such as invoices.
4) Permission strings — a silent rejection cause
Every permission needs a sentence explaining why, shown at the moment it is requested. Generic wording such as "we need your location to improve your experience" is weak. Be specific: "we need your location to calculate accurate prayer times in your area." A practical rule that serves both review and usability: never request a permission on first launch — request it at first genuine use.
5) Automated upload errors — no human involved
| Error | What it means in practice |
|---|---|
| ITMS-90683 | You use a capability such as the microphone with no purpose string in the app's settings |
| Duplicate build number | You uploaded a build number already used — increment it even if the code did not change |
| Version string mismatch | "3" and "3.0.0" are treated as different versions — fix the format and never mix them |
| Missing privacy manifest | Modern apps need a manifest declaring data collection and reasons for using certain APIs |
Pre-submission checklist
Guest mode showing real content; report and block if users post; working in-app account deletion; a specific sentence per permission requested in context; a working privacy policy link and terms; a demo account ready for the reviewer if login needs an SMS code; and review notes explaining your business model, especially if money or commission moves outside the app.
We handle this whole stage as part of mobile app development — from the developer account to approval — and deal with any rejection and resubmit until it passes.
