Why apps get rejected from the App Store, and how to avoid it
The App Review rejections that come up most, the guideline behind each, and the checklist that stops them before you submit.
Meer Habib
Senior Mobile Engineer · Chittagong
Most App Store rejections aren't about the idea. They're about something small the reviewer hit in the first five minutes: a login that didn't work, a paywall with no way to restore, a permission prompt that didn't say why. The good news is that the same few reasons come up again and again, and every one of them can be checked before you press Submit.
I run my own App Store developer account with nine live apps, and I ship client apps through review too. This is the checklist I go through before every submission.
The reviewer walks one path
A reviewer installs your build on a real device, opens it, signs in, tries the main thing the app is for, looks at what you charge for, and pokes at settings. Each of those steps is checked against a specific part of the App Review Guidelines.
If you walk that same path on the release build, on a clean device, signed out, most rejections never happen.
The usual reasons, and the fix for each
It crashes, or looks unfinished (2.1)
App Completeness is the most common one. A crash on launch, a button that does nothing, "Lorem ipsum" on a screen nobody looked at, a link to a page that 404s. Test the release build, not the debug one, on the oldest device and iOS version you support.
The reviewer can't get in (2.1)
If your app has a login, give the reviewer a demo account in the App Review notes, and make sure it has data in it. An empty account on an app that only makes sense with content looks broken. If a feature needs special hardware, a code or a server switch, say so in the notes, plainly.
The listing promises more than the build does (2.3)
Screenshots, the description and the "What's New" text have to describe the app that's actually in review. Listings drift as a product changes, so I rewrite mine against the build, line by line. Every claim should map to a screen you can open.
Digital goods sold outside in-app purchase (3.1.1)
If people pay to unlock something they use inside the app (premium features, credits, content), it goes through Apple's in-app purchase, with a way to restore purchases. Subscriptions need the price, the period and links to your terms and privacy policy shown before someone pays. Physical goods and real-world services are different: those can use your own checkout.
A website in a wrapper (4.2)
Minimum Functionality rejects apps that are a website in a web view. If the app does nothing a browser tab couldn't, it needs a reason to exist: offline use, notifications, the camera, widgets, something native.
Social login with no private option (4.8)
If you offer login through Google, Facebook or another third party, you also need an option that collects only a name and email and lets people keep their email private. Sign in with Apple meets that requirement and is the usual answer.
Vague permission prompts (5.1.1)
Every permission prompt needs a purpose string that says, in one sentence, what the person gets by allowing it. Ask in context, when the feature is used, not all at once on first launch. And don't ask for anything the app doesn't use: a leftover camera permission is an easy rejection.
No way to delete the account (5.1.1(v))
If people can create an account in your app, they have to be able to delete it from inside the app. A link to email support isn't enough. Deleting should remove the account and its data, not just sign out.
The paperwork that also counts
- Privacy nutrition labels in App Store Connect have to match what the app and its SDKs actually collect. Analytics and crash reporting count.
- A privacy manifest for your app and the SDKs that need one. Missing ones can stop the upload before a person ever sees the build.
- Tracking. If you track people across other companies' apps or sites, ask with App Tracking Transparency first.
- A real support URL and a privacy policy URL that both load and lead somewhere a person answers.
Google Play is less hands-on per build, but it has its own list: the Data safety form, declarations for sensitive permissions like background location, the current target API level, and for new personal developer accounts, a closed test with real testers before production.
If it gets rejected anyway
A rejection isn't final. It comes with the guideline and a note. If the reviewer was right, fix it and resubmit. If they missed something, reply in the Resolution Center with exactly where to find it, and a screen recording helps. If you still disagree, you can appeal to the App Review Board.
For a longer look at one real submission, here's how I got Mend ready for review: consent first, honest permissions, and a listing that matches the build.
Store listing, review and release are part of every app I build. If yours keeps bouncing off review, or you want it to go through the first time, send me what you're shipping and I'll walk the reviewer's path with you.
Building something like this?
Booking new projects for Q4. Replies within 24h.