Guide · 6 min read
Why apps get rejected from the App Store
A rejection is not a verdict on your app. It is usually one specific guideline, and the same handful come up again and again. Knowing them before you submit turns a two-week surprise into a checklist.
Incomplete submissions
The most common rejection is not about your app at all. It is a build that crashes on the reviewer's device, a demo account that does not work, or a feature the reviewer could not reach.
If any part of your app sits behind a login, Apple needs working credentials. If a feature needs specific data to be visible, the account you provide needs that data in it. Reviewers do not go hunting.
Not enough to be an app
Apple rejects apps that are a website in a shell, or that do nothing a mobile browser could not. If your app's entire function is displaying pages you already publish, expect a problem.
The bar is roughly this: does it use the device for something? Notifications, offline access, the camera, location, or a genuine native interface. An app needs a reason to be an app.
Privacy, and the parts people miss
Every app needs a privacy policy at a working URL, and the privacy labels on your listing must match what the app actually does. Mismatches get caught.
Two specifics that catch people out: if you ask for a permission, the prompt has to explain why in plain language, and if your app has accounts, it needs a way to delete an account from inside the app. That last one is not optional and is a frequent late discovery.
Payments through the wrong channel
Digital goods and subscriptions consumed inside the app go through Apple's in-app purchase, not your own payment form. Physical goods and real-world services do not.
Subscriptions also need the terms visible before purchase, working restore, and a clear description of what renews and when. A subscription screen that hides the price is a reliable rejection.
Placeholder content
Lorem ipsum, a beta label, a broken link in your listing, screenshots that do not match the app. Reviewers read the listing as carefully as the binary.
This one is entirely avoidable and it is genuinely common.
What to do when it happens
Read the actual guideline number in the message rather than the summary. Fix the specific thing. Reply in Resolution Center explaining what changed, because a clear reply often resolves a misunderstanding faster than a resubmission.
And do not treat a rejection as unusual. Plan for one round and it stops being a crisis.
Building something like this?
We handle submission and the response when Apple pushes back, so a rejection is our problem rather than yours.