App review is more predictable than its reputation suggests. The rejections that delay releases cluster into a small number of guideline sections, and nearly all of them are avoidable at design time rather than negotiable at submission time. The expensive ones are the architectural ones, because they cannot be fixed in a patch release.
01The rejections that cost weeks, not days
Payment routing is the big one. If your app unlocks digital content or features, Apple expects that purchase to go through in-app purchase. Building a subscription flow that points at your own web checkout is not a submission problem you fix with a note to the reviewer; it is a business model that has to change or an exemption you have to genuinely qualify for.
Account deletion is now mandatory for any app that supports account creation, and it must be reachable in-app rather than by emailing support. Teams that treat deletion as a backend ticket queue get rejected.
Sign in with Apple is required when you offer other third-party logins. Adding it late means touching identity, which is rarely a small change.
02The ones that cost a day
These are the routine ones. Each is cheap to fix and cheap to avoid entirely.
- Permission strings that do not explain the actual use. 'This app needs camera access' is a rejection; explaining what the camera is for is not.
- Placeholder content, lorem ipsum or obviously broken links in the build you submitted.
- A demo account that does not work, or a feature behind a login the reviewer cannot reach. Provide working credentials and any second-factor bypass.
- Crashes on the reviewer's device, frequently an older model or a fresh install with no data - test the empty state on the oldest OS you support.
- Metadata that references other platforms, or screenshots that do not match the current UI.
03Working the process rather than fighting it
The review notes field is underused. A reviewer with no context has to guess what your app does, and guessing produces rejections. Explain the flow, provide credentials, and state plainly why anything unusual is compliant.
When you believe a rejection is wrong, the resolution channel matters. A reply in Resolution Center that cites the specific guideline and explains why your implementation satisfies it is more effective than resubmitting unchanged, which usually produces the same result from the same automated signal.
Expedited review exists and is genuinely granted for real incidents. Using it for a normal release burns credibility you will want during an actual outage.
04Building so review is boring
The teams that never think about review are the ones that decided the constraints early: purchases through in-app purchase, deletion in-app, permissions requested at the point of use with honest strings, and no dynamic behaviour that changes what the app does after approval.
That last one matters more than it used to. Remote configuration that materially changes functionality post-review is a guideline violation and a plausible reason for removal rather than rejection - a considerably more expensive outcome.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer