---
title: "Why Apps Get Rejected From the App Store (2026 Guide) | Superapp"
description: "Why Apple rejects apps in 2026: the most common App Store rejection reasons, why AI-built and no-code apps get flagged more, and how to avoid each one."
image: https://www.superappp.com/lovable-uploads/bc4914af-9cbc-4b4c-a764-13dde52ee116.webp
canonical_url: https://www.superappp.com/blog/why-apps-get-rejected-from-the-app-store-2026-guide
md_url: https://www.superappp.com/blog/why-apps-get-rejected-from-the-app-store-2026-guide.md
---
## App Store Rejection: The Short Answer

Most App Store rejections are not the reviewer being harsh, they are the same handful of fixable problems: crashes, a missing or inaccurate privacy policy, mismatched screenshots, no in-app account deletion, and apps that feel like a repackaged website. Apple rejects roughly one in four submissions, so a rejection is normal and almost always fixable in a day. The one group that gets flagged disproportionately: AI-built, no-code, and web-wrapper apps, because of how they are built.

> **Quick answer: why did Apple reject my app?** Apple reviewed 7.77 million submissions in 2024 and rejected about 1.93 million of them, roughly one in four, according to its own App Store Transparency Report. The most common reasons are crashes and bugs (Guideline 2.1), a missing or inaccurate privacy policy (5.1.1), inaccurate metadata or screenshots (2.3), no in-app account deletion (5.1.1(v)), and minimum functionality, an app that is essentially a website in a wrapper (4.2). Apps built with AI or no-code tools hit the functionality and code rules (4.2, 4.3 spam, and 2.5.2 executing code) more often, because web wrappers and templated output are exactly what those rules target. Almost every rejection is a request for changes, not a ban, and you can resubmit as many times as you need.

## How Often Does Apple Reject Apps?

Apple rejects about one in four app submissions, so a rejection notice is common, not a sign your app is doomed. In its 2024 App Store Transparency Report, Apple reported reviewing 7.77 million submissions and rejecting roughly 1.93 million of them, a rejection rate near 25 percent that rose year over year. Notably, of the submissions rejected in that period, a large share were eventually approved after developers fixed the issue and resubmitted, which tells you most rejections are procedural rather than final.

The takeaway is to treat a rejection like a bug report. Apple cites the specific guideline number in the Resolution Center, you fix that item, and you resubmit. The rest of this guide covers the specific guidelines that trigger the most rejections and how to clear each one.

## The Most Common App Store Rejection Reasons

Apple organizes review around five pillars, Safety, Performance, Business, Design, and Legal, but most rejections cluster in a short list. Here are the reasons that trip up the majority of submissions, with the guideline each one cites.

| Guideline | Rejection reason | What triggers it |
| --- | --- | --- |
| 2.1 | Crashes and bugs | App crashes, freezes, broken flows, placeholder content, or missing reviewer test-account credentials |
| 5.1.1 | Privacy policy | Missing or inaccurate privacy policy link, or App Privacy labels that do not match the app |
| 5.1.1(v) | Account deletion | App allows sign-up but has no in-app way to delete the account |
| 2.3 | Inaccurate metadata | Screenshots, description, or pricing that do not match the live app |
| 4.2 | Minimum functionality | A web-wrapper or "repackaged website" with no real native value |
| 4.3 | Spam / copycat | App is too similar to existing apps or a templated duplicate |
| 5.1.2 | Data and tracking | Collecting data or tracking users without consent or the ATT prompt |
| 2.5.2 | Executing code | App downloads, installs, or runs code that App Review never inspected |
| 3.1.1 | In-app purchase | Selling digital goods through an external payment link instead of StoreKit |

Apple's own data points to crashes under Guideline 2.1 as the single largest category of unresolved rejections, and privacy under 5.1.1 as one of the most frequent triggers overall. Two of these, minimum functionality (4.2) and executing code (2.5.2), are where modern AI and no-code apps run into trouble most, which is worth its own section.

## What the Rejection Data Shows (and the React Native vs Swift Question)

Apple does not publish rejection rates broken down by framework, so any claim that "React Native apps are rejected X percent more than Swift" is an invented number, there is no verified statistic comparing the two. What Apple does publish, in its 2024 App Store Transparency Report, is the rejection count by guideline category, and that is where the build-approach signal actually shows up.

| Guideline category | 2024 rejections | What it covers |
| --- | --- | --- |
| Performance | 1,235,471 | Crashes, bugs, broken builds, placeholder content (2.1) |
| Legal | 445,696 | Privacy, data use, regulated categories |
| Design | 378,300 | Copycats, minimum functionality, and spam (4.2, 4.3) |
| Business | 209,845 | In-app purchase and payment rules |
| Safety | 116,105 | Objectionable content and UGC moderation |
| Other | 23,659 | Everything else |

A single submission can be cited under more than one category, so these counts sum to more than the roughly 1.93 million rejected submissions. The category that speaks to how an app is built is Design, which Apple explicitly defines as covering "copycat apps, apps with minimum functionality, and spam." That is the 4.2 and 4.3 bucket, it accounted for 378,300 rejections in 2024, and it is the bucket a WebView-wrapper app is most exposed to.

Here is the honest version of the React Native versus Swift question. React Native is not itself a rejection risk, a well-built React Native or Expo app renders real native views and clears Guideline 4.2 just as a Swift app does. What triggers 4.2 is a WebView wrapper, an app that is essentially a website loaded in a browser shell with no native layer, which is what many no-code and "website to app" tools produce. So the real dividing line in the rejection data is native experience versus web wrapper, not React Native versus Swift. A native Swift app lands in the Design bucket only if it is genuinely thin, a WebView wrapper is exposed by default, and React Native sits wherever its native layer puts it.

## Why AI-Built and No-Code Apps Get Rejected More Often

Apps built with AI or no-code tools get flagged disproportionately because the shortcuts that make them fast to build are exactly what three guidelines target. This is not a knock on building with AI, it is a structural reality of how App Review works.

| Guideline | The trap | Why AI/no-code apps hit it |
| --- | --- | --- |
| 4.2 Minimum functionality | "Repackaged website" | Many no-code and web-to-app tools output a WebView wrapper around a web app, the exact thing 4.2 rejects |
| 4.3 Spam / copycat | Templated sameness | Template-based builders can produce apps that look and behave like dozens of others |
| 2.5.2 Executing code | Running un-reviewed code | Platforms that push updates or interpret code at runtime can run logic App Review never saw |

Guideline 4.2 is the big one. Apple's wording asks that an app "elevate it beyond a repackaged website," so if Safari can do everything your app does, Apple asks why the app exists. A true native app with real device features, push notifications, offline support, and native navigation clears this bar in a way a WebView wrapper cannot.

The takeaway is not that native tools are a magic pass and web tools are doomed, it is about output. A genuinely native app with real device features clears 4.2 and does not run into 2.5.2, while a WebView wrapper is exposed by default. Native output does not exempt you from the universal rules, though, you still ship a privacy policy, in-app account deletion, and accurate metadata like everyone else. Native helps with the functionality and code categories, not the compliance paperwork. For the deeper technical comparison, see [native Swift vs React Native](https://www.superappp.com/blog/native-swift-vs-react-native-expo-in-2025-2026).

## The Anything Case: What Guideline 2.5.2 Means

The clearest recent example of the code rule is Anything, a fast-growing AI app builder that Apple removed from the App Store in 2026 under guideline 2.5.2. That guideline blocks apps which download, install, or execute code that App Review has not inspected, and Apple's concern was that a platform advertising native app creation could run code the reviewer never saw. The Anything app was pulled around March 26, briefly reinstated in early April, and the dispute stayed contested through mid-April, with the company leaning on web deployment and alternative distribution in response.

The lesson is not "avoid AI builders." It is that if your build pipeline can execute code at runtime or push logic outside of review, guideline 2.5.2 is a live risk, and you should plan your distribution around it. Apps whose full behavior is compiled and inspectable at review time do not run into 2.5.2 the same way.

## Do You Need to Upload a Demo Video for App Review?

Not for every app, but this is one of the most important recent shifts in review, and it catches a lot of teams off guard: Apple increasingly requires a demo video in your App Review notes when the app is hard for a reviewer to test, and a missing one is a common cause of Guideline 2.1 delays and rejections. Apple does not ask every submission for a physical-device recording. But if a feature depends on special hardware, needs a specific configuration, is region-locked, or cannot be fully exercised with a normal demo account, you are now expected to attach a short walkthrough so the reviewer does not have to guess how the app works.

What to record is straightforward. Capture the core flow from launch to the main user action, and include any login, account deletion, purchase, and permission prompts that are part of the app, plus moderation tools if it has user-generated content. Keep it short, show the real build rather than marketing footage, and link or attach it in the App Review Information section of App Store Connect. This is separate from the optional App Preview video on your store listing, the review demo video is for the reviewer, not for shoppers.

This matters more for AI-built and unconventional apps specifically. If your builder produces a flow a reviewer would not expect, or the app leans on a backend, hardware, or configuration the reviewer cannot reach, a 30-second demo video attached to the review notes is often the difference between a clean pass and a Guideline 2.1 "we were unable to review your app" bounce. When your app is not fully testable out of the box, record one and link it before you submit rather than waiting for the reviewer to ask.

## How to Avoid App Store Rejection

Start with the most structural decision, because it removes an entire class of rejections at once: build a genuinely native app, not a web wrapper. The Design bucket (4.2 minimum functionality and 4.3 copycat or spam) and the 2.5.2 code-execution trap simply do not apply to a real native app the way they do to a wrapper, so choosing native output is the single biggest thing you can do to lower your rejection odds before you write a line of metadata. If you can write Swift, that means shipping native Swift with real navigation and device features. If you are non-technical and cannot code, the move is to use an AI builder that outputs native Swift rather than a WebView wrapper, so you get native output without hiring a developer. As a disclosure, Superapp is our product, so weigh this accordingly and test the free tier first: [Superapp](https://www.superappp.com) turns a plain-English description into native Swift for iPhone, iPad, Apple Watch, and Mac and hands you the Xcode project, which keeps you clear of the 4.2 and 2.5.2 traps that catch web-wrapper tools. Native output does not clear you of the universal rules below, you still ship a privacy policy, account deletion, and accurate metadata like everyone else, but it takes the whole Design and code-execution category off the table.

Beyond that first decision, most first-submission rejections come from the same compliance items, and they are all preventable before you hit submit. Run this checklist as a "reviewer pass" on a clean device.

Ship a working privacy policy linked both in App Store Connect and inside the app, and make sure your App Privacy labels actually match the SDKs you use (5.1.1). If your app allows account creation, add a visible in-app delete-account flow that truly erases the data, not an email-us workaround (5.1.1(v)). Take screenshots from the live app on real devices, and make sure your description and pricing match what a reviewer will see (2.3). Provide working test-account credentials in the App Review notes for any login-gated feature, and scrub every placeholder or "coming soon" screen (2.1). Test on multiple physical devices and iOS versions, not just the simulator, to catch the crashes that cause the most rejections (2.1). If your app uses any AI service, add a consent screen naming the provider and the data shared, a requirement Apple began enforcing in late 2025. And build with the current Xcode and SDK, since Apple made the iOS 26 SDK mandatory for new submissions as of April 2026. Finally, if any part of your app is hard to test out of the box, attach a short demo video in the App Review notes before you submit rather than waiting to be asked.

If native functionality is your concern under 4.2, add genuine device features rather than wrapping a website. The single best way to clear the minimum-functionality bar is to ship a real app, not a bookmark.

## What to Do If Your App Is Rejected

A rejection is a request for changes, not a ban, and you can resubmit as many times as you need. Read the exact guideline Apple cites in the Resolution Center, reproduce and fix that specific item, then reply in the same thread noting what you changed and where to verify it. If the rejection is a metadata issue you can often resubmit the same binary after editing App Store Connect fields; if it is a binary issue like a crash or a code violation, you upload a new build.

If you believe the rejection is a genuine misreading, you can appeal to the App Review Board, and roughly one in five appeals results in a reversal, mostly on metadata disputes. Keep the appeal short and reference the guideline directly.

## How Long Does App Store Approval Take by Category?

Apple's only official figure is that about 90 percent of submissions are reviewed within 24 hours. In practice, the time to approval varies widely by category and submission type, from a few hours for a routine update to a week or more for a first submission in a regulated category. Apple does not publish average review times broken down by app category, so the ranges below come from developer reports and third-party trackers rather than from Apple, and they shift with reviewer load and season.

| Submission type or category | Typical reported review time |
| --- | --- |
| Update from an established account | 5 hours to 1 day |
| Standard new app, no sensitive category | 24 to 48 hours |
| First submission on a brand-new developer account | 2 to 5 days |
| Finance apps (licensing and regulatory checks) | Often several days |
| Kids category (COPPA and child-safety review) | Often several days |
| Health apps | Often several days |
| Apps with user-generated content or social features | Longer, moderation review adds time |
| Mac App Store apps | Reported 5 to 10 days |

Two things stretch these numbers further. Regulated and child-directed categories such as Finance, Kids, and Health are routed to senior reviewers and often need licensing or compliance proof, which adds days. And peak seasons, especially September around new iOS releases and December before the holiday freeze, slow the whole queue. Anything that makes your build harder to review, missing demo credentials, an unclear flow, or a demo video you did not attach, also pushes you into the slow tail, because the clock effectively restarts each time a reviewer has to stop and ask for more.

## Frequently Asked Questions

**Why did Apple reject my app?**
The most common reasons are crashes or bugs (Guideline 2.1), a missing or inaccurate privacy policy (5.1.1), no in-app account deletion (5.1.1(v)), screenshots or metadata that do not match the app (2.3), and minimum functionality, meaning a web wrapper with no native value (4.2). Apple cites the specific guideline in the Resolution Center, so read that number first.

**How often does Apple reject apps?**
About one in four. Apple's 2024 App Store Transparency Report reported reviewing 7.77 million submissions and rejecting roughly 1.93 million. A large share of those were later approved after developers fixed the issue and resubmitted, so most rejections are procedural.

**Why do AI-built or no-code apps get rejected more often?**
Because web-wrapper output trips minimum functionality (4.2), templated apps trip spam and copycat rules (4.3), and platforms that run code at runtime trip guideline 2.5.2 on executing un-reviewed code. Native apps with real device features are less exposed to those specific rules, though they still must meet the universal privacy and metadata requirements.

**What is guideline 2.5.2?**
Guideline 2.5.2 blocks apps that download, install, or execute code that App Review has not inspected. It is the rule Apple used to remove the AI app builder Anything from the App Store in 2026. Apps whose behavior is fully compiled and inspectable at review time generally do not run into it.

**Is an App Store rejection permanent?**
No. A rejection is a request for changes, not a ban. You can fix the cited issue and resubmit as many times as needed. Permanent bans are rare and reserved for repeated violations, fraud, or apps that harm users.

**Can I appeal an App Store rejection?**
Yes. Reply in the Resolution Center explaining why you think the rejection was a misreading, and if that fails, escalate to the App Review Board. About one in five appeals is reversed, mostly for metadata issues. Appeals can add a few days.

**How long does App Store approval take by category?**
Apple's only official figure is that about 90 percent of submissions are reviewed within 24 hours, and it does not publish average times by app category. In practice, developer reports put a standard new app at 24 to 48 hours, an update from an established account as low as 5 hours, and a first submission on a new account at 2 to 5 days. Regulated or child-directed categories such as Finance, Kids, and Health run to several days because they go to senior reviewers, and Mac App Store apps are reported to take around 5 to 10 days. Peak seasons in September and December slow everything.

**Are React Native apps rejected more often than native Swift apps?**
Apple does not publish rejection rates by framework, so there is no verified "React Native versus Swift" rejection percentage. React Native is not itself a rejection risk, a well-built React Native or Expo app renders real native views and passes Guideline 4.2 like a Swift app. What Apple's data does show is that 378,300 rejections in 2024 fell under the Design category (copycats, minimum functionality, and spam), the bucket that catches WebView-wrapper apps with no native layer. The real dividing line is native experience versus web wrapper, not React Native versus Swift.

**Do you need a demo video to submit an app to the App Store?**
Not for every app. Apple does not require a physical-device recording for standard submissions, but reviewers increasingly require a demo video in the App Review notes when an app is hard to test, for example when it depends on special hardware, a specific configuration, region-locked content, or flows a normal demo account cannot reach. A missing walkthrough in those cases is a common Guideline 2.1 delay or rejection, so attach a short recording of the core flow when your app is not fully testable out of the box. This is separate from the optional App Preview video on your store listing.

**Does building a native app guarantee approval?**
No. Native output helps you clear the functionality and code rules (4.2 and 2.5.2) that catch web-wrapper and hybrid apps, but every app, native or not, must still ship a privacy policy, in-app account deletion, accurate metadata, and a crash-free build to pass review.

## References

- [Apple: 2024 App Store Transparency Report (PDF)](https://www.apple.com/legal/more-resources/docs/2024-App-Store-Transparency-Report.pdf) - submission and rejection figures
 - [Apple Developer: App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) - the official guideline text
 - [QAwerk: Why Apps Get Rejected, the most common violations in 2026](https://qawerk.com/blog/app-store-rejection-reasons/) - guideline breakdown and Apple data analysis
 - [App Lander: App Store Rejection Reasons in 2026](https://www.applander.io/blog/app-store-rejection-reasons-2026) - the 15 most common reasons with guideline text
 - [Lexogrine: Apple App Store Review in 2026](https://lexogrine.com/blog/apple-app-store-review-requirements-2026) - demo video and review-readiness requirements
 - [MobiLoud: Will Your Webview App Be Rejected?](https://www.mobiloud.com/blog/app-store-review-guidelines-webview-wrapper) - Guideline 4.2 and the WebView-wrapper vs native distinction
 - [LowCode: App Store Review Time in 2026](https://www.lowcode.agency/blog/app-store-review-time) - reported review times by submission type and category
 - [Apple Developer: App Review](https://developer.apple.com/distribute/app-review/) - official 24-hour review figure
 - [TechCrunch: How Anything is rebuilding after getting booted from the App Store twice](https://techcrunch.com/2026/04/14/how-vibe-coding-app-anything-is-rebuilding-after-getting-booted-from-the-app-store-twice/) - guideline 2.5.2 case
 - [MacRumors: Apple Pulls Vibe Coding App 'Anything' From App Store](https://www.macrumors.com/2026/03/30/apple-pulls-vibe-coding-app/) - guideline 2.5.2 removal
 - [Superapp](https://www.superappp.com) - native Swift iOS apps you own, no Mac
 - Related: [how difficult is it to publish an app to the App Store](https://www.superappp.com/blog/how-difficult-is-the-process-for-publishing-an-app-to-the-apple-store) and [native Swift vs React Native](https://www.superappp.com/blog/native-swift-vs-react-native-expo-in-2025-2026)

## Keep reading

[How to Build Apps With AI in Xcode (2026 Guide)

Aug 6, 2026](https://www.superappp.com/blog/how-to-build-apps-with-ai-in-xcode-2026-guide) [Anything AI App Builder Review (2026): Pricing & Real Reviews

Aug 5, 2026](https://www.superappp.com/blog/anything-ai-app-builder-review-2026) [iOS Prototyping Tools in 2026 (and How to Ship a Real App)

Aug 5, 2026](https://www.superappp.com/blog/ios-prototyping-tools-in-2026-and-how-to-ship-a-real-app)

## Build iOS apps with AI

Turn your ideas into production-ready iOS apps. Fast and easy.

[Get started](https://www.superappp.com/)