Why Apps Get Rejected From the App Store (and How to Avoid It)
Getting an app rejected feels personal the first time. It isn't. Apple's App Review team runs every submission against a public rulebook — the App Store Review Guidelines — and the overwhelming majority of rejections are boring, fixable compliance issues, not judgments about whether your app is good. Understanding why apps get rejected from the App Store ahead of time is the difference between shipping on the first try and burning a week on back-and-forth in Resolution Center.
This post maps the real 2026 rejection reasons to the exact guideline numbers Apple cites, so when you get that email you know precisely what to fix. It pairs with our guide on publishing an app without code and the app store submission checklist — read those to prevent rejections; read this to understand and resolve them.
How App Store rejection actually works
When your app fails review, Apple doesn't just say "no." You get a message in Resolution Center (inside App Store Connect) citing one or more guideline numbers and, usually, a short explanation or screenshot. You fix the issue, reply, or upload a new build, and resubmit. There's no penalty on your account, and there's no limit on resubmissions.
The guidelines are organized into five sections, and rejections cluster in a predictable way:
- Safety (objectionable content, user-generated content, kids)
- Performance (bugs, completeness, accurate metadata)
- Business (payments, subscriptions, acceptable business model)
- Design (minimum functionality, spam, copycats)
- Legal (privacy, data collection, intellectual property)
Below are the reasons that actually catch indie and no-code makers, ranked by how often they bite.
The most common App Store rejection reasons in 2026
1. Incomplete information — Guideline 2.1 (App Completeness)
This is the number-one bucket. Guideline 2.1 covers apps that reviewers can't fully evaluate. In practice that means:
- No demo account. If your app has a login, you must provide working demo credentials (or a sign-in flow the reviewer can complete) in the App Review Information notes. No credentials = instant 2.1 rejection because the reviewer literally can't get in.
- Crashes or broken features during review, including features behind a paywall the reviewer can't reach.
- Placeholder content — "Lorem ipsum," empty screens, or "coming soon" buttons.
- Backend not live. If your app calls an API that's off or in a staging state during review, it reads as broken.
Avoid it: Provide demo login credentials in review notes, test every flow on a real device, and make sure your backend is production-ready before you submit.
2. Privacy policy problems — Guideline 5.1.1 (Data Collection and Storage)
A missing, broken, or inaccurate privacy policy is one of the top rejections every year. Apple requires a working privacy policy URL in App Store Connect, and every app must have one — even a simple app that "doesn't collect anything" still needs a policy that says so. The link has to actually load; a 404 fails 5.1.1 on its own.
Avoid it: Publish a real, reachable policy before you submit. Our do-I-need-a-privacy-policy guide explains exactly what Apple requires, and the app privacy policy generator creates a hosted, mobile-specific policy with a live URL in minutes.
3. App Privacy label contradicts the app — Guideline 5.1
Separate from the policy itself, the App Privacy "nutrition label" you fill out in App Store Connect must match what your app actually does. If you declare "no data collected" but your app has analytics, crash reporting, or a sign-up form that captures an email, that contradiction gets flagged. This is one of the fastest-growing rejection categories.
Avoid it: Inventory every SDK and every field your app collects, then make the label, your privacy policy, and reality all agree.
4. Broken links — Guideline 1.5 (Support URL) and 2.1
Your support URL must work and lead to a page where users can actually get help. Reviewers click it. A dead support link, a marketing page with no contact path, or a link to a social profile can trigger a rejection. Broken in-app links count too.
Avoid it: Add a real support page with a contact method, and click every URL in your listing before submitting.
5. Minimum functionality / "web wrapper" — Guideline 4.2
Guideline 4.2 requires apps to be more than a repackaged website or a thin app that provides little lasting value. Apps that are just a wrapper around a mobile website, or that a user could get identically in Safari, get rejected. This catches simple no-code apps that don't use any device capabilities or offer native value.
Avoid it: Make sure your app does something a bookmark can't — push notifications, offline behavior, native navigation, camera/location use, saved state. Build genuine functionality, not a browser in a box.
6. Misleading or off-spec metadata — Guideline 2.3
Guideline 2.3 covers "accurate metadata." Rejections here include:
- Screenshots that don't reflect the actual app, or that are marketing collages instead of real UI
- Screenshots at the wrong dimensions for the device size
- Keyword stuffing in the name/subtitle, or naming competitors
- A description that promises features the app doesn't have
Avoid it: Use honest screenshots at Apple's exact sizes — iPhone 6.9" is 1320×2868 and iPhone 6.7" is 1290×2796. The App Store screenshot generator exports at those exact dimensions so the console never bounces them for size, and it lets you show real screens with clear captions rather than misleading art.
7. Payments outside Apple's system — Guideline 3.1.1 (In-App Purchase)
If you unlock digital content, features, or subscriptions inside the app, Apple requires you to use In-App Purchase, not an external payment link. Pointing users to a website to pay for digital goods is a classic 3.1.1 rejection. (Physical goods and real-world services are the exception — those don't use IAP.)
Avoid it: Route digital unlocks through IAP; reserve external checkout for physical goods and services only.
8. Sign in with Apple missing — Guideline 4.8
If your app offers third-party or social login (Google, Facebook, etc.) as a sign-in option, you generally must also offer Sign in with Apple or an equivalent privacy-preserving option.
Avoid it: If you add "Continue with Google," add "Sign in with Apple" alongside it.
9. Newer 2026 hard stops
Two changes worth knowing this year:
- AI/data-sharing consent. Apps that send personal data to third-party AI services are expected to disclose the provider and get user consent before sharing. If your app pipes user input to an external model, add a clear consent step.
- SDK requirement. Apps must be built against a current SDK. If you're on Adalo, the platform handles the SDK for you at build time — one of the quiet advantages of publishing an Adalo app to the stores rather than maintaining a native toolchain yourself.
10. Spam, copycats, and templated apps — Guideline 4.3
Guideline 4.3 targets apps that duplicate something already on the store or that are clearly cranked out from a template with only cosmetic differences. This is the one that occasionally catches no-code makers who ship near-identical apps for multiple clients from one project. Apple wants each app to have a distinct identity and genuine value.
Avoid it: Give each app its own name, icon, screenshots, description, and — critically — its own real content and purpose. Don't ship five recolored clones of the same template.
11. Kids and age-rating issues — Guideline 1.3 / 5.1.4
If your app targets or appeals to children, it faces stricter rules: no third-party analytics or advertising that isn't kid-appropriate, tighter data-collection limits, and an accurate age rating. A wrong age rating alone can trigger a rejection.
Avoid it: Set an honest age rating in the App Store Connect questionnaire, and if kids are an audience, review the Kids Category requirements before submitting.
Rejection reasons at a glance
| Reason |
Guideline |
Fastest fix |
| No demo login / broken feature |
2.1 |
Add working credentials to review notes; test on device |
| Missing/broken privacy policy |
5.1.1 |
Publish a live policy URL |
| Privacy label contradicts app |
5.1 |
Match label to actual data collection |
| Broken support/marketing link |
1.5 |
Add a working support page |
| Web wrapper / thin app |
4.2 |
Add real native value |
| Misleading or off-size metadata |
2.3 |
Honest screenshots at exact sizes |
| External payment for digital goods |
3.1.1 |
Use In-App Purchase |
| Missing Sign in with Apple |
4.8 |
Add it alongside social logins |
| Copycat / templated app |
4.3 |
Give each app a distinct identity |
| Wrong age rating / kids rules |
1.3, 5.1.4 |
Answer the rating questionnaire honestly |
Pre-submission checklist to avoid rejection
- [ ] Working demo login credentials in App Review notes (Guideline 2.1)
- [ ] Every feature works on a real device; no crashes, no placeholders
- [ ] Privacy policy URL is live and loads (5.1.1)
- [ ] App Privacy label matches actual data collection (5.1)
- [ ] Support URL works and has a contact method (1.5)
- [ ] App offers real native value beyond a website (4.2)
- [ ] Screenshots are honest and at exact sizes (2.3)
- [ ] Digital purchases use In-App Purchase (3.1.1)
- [ ] Sign in with Apple present if other social logins are (4.8)
- [ ] AI data-sharing consent in place if applicable
What to do when you're rejected anyway
- Read the guideline number in Resolution Center — it tells you the exact category.
- Fix the specific issue. Don't guess; address what's cited.
- Reply or resubmit. Metadata-only fixes (privacy label, screenshots, description) often don't need a new build and clear faster.
- Appeal if you genuinely disagree. Apple has a formal appeal process, but use it sparingly and with evidence.
Once you've fixed and resubmitted, you're back in the queue. For how long that queue actually takes, see how long App Store review takes.
Frequently asked questions
What is the most common reason apps get rejected from the App Store?
Metadata and privacy issues, not code. The top offenders are a broken or missing support/privacy URL (Guideline 1.5 and 5.1.1), an App Privacy label that contradicts what the app actually collects, and incomplete information under Guideline 2.1 such as missing demo login credentials.
Does getting rejected hurt my app or my developer account?
No. A rejection is not a strike against your account. Apple tells you the specific guideline you missed in Resolution Center, you fix it, and you resubmit. Most rejections are resolved in one round and don't reset your place in a meaningful way.
How fast can I resubmit after an App Store rejection?
Immediately. Once you've fixed the issue and (if needed) uploaded a new build, you resubmit from App Store Connect and re-enter the review queue. Fixes that don't require a new binary — like a metadata or privacy-label correction — often clear faster on the second pass.