Why Apps Get Rejected from the App Store in 2026: Data-Backed Reasons and How to Avoid Each

Every submission moves through the same gate — most make it through, and most that don't come back and try again.

App Store rejection is not a review gamble. It's a development-process problem. Two-thirds of rejections land in the Performance category — crashes, broken links, placeholder content, missing demo accounts. These are checkable before submission. Using Apple's own 2025 transparency data and the four rule changes that landed in the last 12 months, you can frame each rejection reason as an architectural decision made months before you hit upload.

The real numbers (not the rumors)

Apple rejected 2.09 million submissions out of 9.1 million reviewed in 2025 — a 23% rejection rate. That rate fell from 24.8% in 2024 and 25.6% in 2023. Review is not getting harsher; submission volume grew 32% while rejections grew 19%.

The headline number hides an encouraging signal: 387,087 rejected submissions were approved after resubmission in 2025 — 18.5% of all rejections eventually passed. A rejection is a round trip, not a verdict. Budget the time, fix the issue, and move on.

One nuance: "rejection rate" measures submissions, not apps. A single app may be resubmitted ten times. The 23% is the percentage of review actions that result in rejection, not the percentage of developers who ever face one.

Stats for publish:

• Rejection rate 2025: 23.0%

• Submissions reviewed 2025: 9,100,620

• Submissions rejected 2025: 2,093,244

• Recovery rate (rejected to approved): 18.5%

What gets you rejected, ranked by volume

The Performance category accounts for 64.7% of all rejections — 1.35 million out of 2.09 million. Legal is second at 23.7% (495,673), Design third at 19.9% (415,532), Business fourth at 13.6% (283,820), Safety fifth at 7.2% (151,159).

The categories sum to more than 100% because one submission typically fails multiple guidelines at once. The average rejected submission breaks 1.3 guidelines. Most developers who see a rejection notice assume it's a single issue. It's usually not. When you resubmit, audit the full guideline set, not just the cited violation.

The #1 reason: your app isn't finished (Guideline 2.1)

Apple says over 40% of unresolved review issues relate to Guideline 2.1 — App Completeness. Placeholder text. Broken URLs. Missing demo accounts. Backends that were offline when the reviewer tested.

These rejections are entirely preventable. You control the code and the build. The fix is architectural: a pre-submission checklist embedded as a CI gate, not a human email.

Before you submit: 1. Search the entire codebase for placeholder strings: "TODO," "FIX ME," "Demo," "Test." Run a regex pass. If it's visible in production, it will be rejected. 2. Test every link in the UI against a live environment. Dead links are instant 2.1. 3. If the app requires a demo account, include it in the submission notes with credentials. 4. Test on the oldest supported OS version and the smallest supported device. 5. If your backend is rate-limited, mention it in the submission notes.

Crashes and bugs — the Performance category

The reviewer opens your app on a real device. First crash is the review over. Performance rejections account for 64.7% of all rejections, and most are crashes caught on first launch.

Testing on TestFlight is not optional. It's a staging environment. Use it as a pre-screen before submission: run it on the oldest supported OS, the smallest supported device, and with realistic data volumes. If it crashes in TestFlight, it will crash in review.

Crashes are not mysterious. Run on real hardware. Use Instruments to profile memory, threading, and networking. The iOS simulator hides memory leaks and race conditions that explode on real devices.

Privacy manifests and SDK debt (the sneakiest blocker)

Every app must include a PrivacyInfo.xcprivacy file since May 1, 2024. Xcode blocks upload if it's missing. But there's a second, harder requirement: every third-party SDK you bundle must also ship its own privacy manifest.

This is a dependency-management problem, not a submission-day problem. When you add a library, check whether it has a privacy manifest. If not, file an issue with the maintainer or find an alternative.

Use Xcode's Privacy Report (Product > Privacy Report) as a pre-flight check. It lists every data access your app and all bundled SDKs are making, with required-reason justifications.

AI consent — the new rule (5.1.2(i), November 2025)

Apple added Guideline 5.1.2(i) on November 13, 2025: apps that share personal data with third-party AI services must name the provider, explain what data is shared, and obtain explicit user consent.

This applies to OpenAI, Anthropic, Google, ElevenLabs, and similar external services. On-device Core ML is exempt.

Build a consent layer as a configurable module: document what gets sent, allow users to disable it, and make it straightforward to swap providers without rebuilding.

Webview wrappers and minimum functionality (Guideline 4.2)

Guideline 4.2.6 rejects apps that are essentially websites wrapped in a webview. Apps that are simply a wrapper around a website, or that just launch a web page without adding functionality, will be rejected.

Template-generated or low-code apps must be submitted by the content owner, not a third-party developer. If you're building a white-label SaaS wrapper, the end customer has to hold the app ID and submit it themselves.

The decision is made at build time: either your app has native value-add, or it doesn't. If not, don't submit it.

Payments, subscriptions, and the Business category

Digital goods sold outside In-App Purchase are instant Guideline 3.1.1 rejection. If you're selling anything digital (courses, digital assets, premium features), Apple gets 15–30% of the revenue through IAP.

Subscription terms must be visible before purchase. Freemium to paid conversion must be opt-in, not buried in settings. The auto-renewal terms, cancellation method, and price must be clear before the user taps "subscribe."

As of July 2026, In-App Purchase and subscriptions are submitted through the same "Add for Review" flow. EU DMA users can offer external purchase links for digital goods, but only with the DMA External Purchase Link Entitlement.

Age ratings, kids category, and the 2025–2026 overhaul

Apple's age-rating system was overhauled on July 24, 2025 with new 13+, 16+, and 18+ tiers. Developers had until January 31, 2026 to complete the updated questionnaire for all live apps. A further update on July 9, 2026 added social-media-specific questions.

If your app targets kids (COPPA applies in the US), the Kids category has hard constraints: 1. No third-party analytics or tracking. 2. No advertising networks. 3. No external links. 4. Parental gates on any paid content.

These are features you either have or don't. Decide before you start development, not during metadata entry.

Xcode 26 and the April 2026 SDK mandate

All submissions have required the iOS 26 SDK / Xcode 26 since April 28, 2026. If your build is targeting iOS 25 or earlier, upload will fail before any reviewer sees it.

Your CI pipeline should be pinned to the latest Xcode release. Running `xcodebuild -version` should tell you immediately whether you're submission-ready.

Google Play: the same problems, different shape

Google does not publish a rejection rate. Their 2025 report says they prevented 1.75 million policy-violating apps and banned 80,000+ developer accounts, but never discloses total submissions reviewed.

The biggest blocker on Google Play is the Data Safety form. It requires you to disclose every SDK you're using and categorize what data each one accesses. Gaps in SDK disclosure are the #1 reason apps are rejected or delisted.

The 16KB memory page-size requirement is enforced by Google Play starting February 1, 2027, for apps targeting API 35+ that use native (NDK) code. Target API 36 became mandatory on August 31, 2026.

You got rejected — now what

Read the rejection notice twice. The reviewer has a template, but the specifics matter. Fix only what was flagged; don't guess at other violations. In the Resolution Center, respond with specifics: what exactly you changed, and ideally a screenshot of the fix.

Budget a week between resubmission and the next announcement. Health, finance, and kids apps take two weeks. If the app is still in review after that window, contact Developer Support with the submission ID.

The 18.5% recovery rate is not luck. Most rejections are fixable. Treat rejection as a step in your process, not a verdict on your idea.

Pre-submission checklist (2026)

Build and SDK: Building with Xcode 26 and iOS 26 SDK (required as of April 28, 2026). App runs on the oldest supported iOS version without crashes. All TestFlight builds are signed and tested on real devices.

Completeness (Guideline 2.1): No placeholder text in the UI (search for "TODO," "FIXME," "Demo," "Test,"). All hyperlinks point to live URLs. Demo account included in submission notes if required.

Privacy and Data: PrivacyInfo.xcprivacy file is present. All bundled third-party SDKs have PrivacyInfo manifests. If using third-party AI services: comply with Guideline 5.1.2(i) consent and disclosure.

Age Ratings: Age rating questionnaire updated to new 13+/16+/18+ schema. If targeting kids: no third-party analytics, no ads, no external links, parental gates in place.

Payments: All digital goods sold through In-App Purchase. Subscription terms, cancellation method, and price visible before purchase.

Content: App is not just a website in a webview (has native functionality). If generated or template-based: submitted by the content owner, not a third-party builder.

Start this checklist during development, not the night before submission. Most rejections are prevention, not recovery.