Most Common App Store Rejection Reasons and Fixes (2026)

The Most Common App Store Rejection Reasons in 2026 (Apple's Real Numbers and Fixes)

The most common reason apps get rejected from the App Store is not a policy dispute, it is that the app did not work properly when a reviewer opened it. Apple reviewed 9,100,620 submissions in 2025 and rejected 2,093,244 of them, about 23%, and Performance issues (crashes, bugs, and incomplete builds under Guideline 2.1) caused more rejections than every other category combined (Choicely). The encouraging part is that most rejections are self-inflicted and fixable: 387,087 submissions were approved in 2025 after an earlier rejection, so a rejection is usually a round trip rather than a verdict (Choicely). This guide ranks the real reasons in Apple's own order of volume, gives the fix for each, and flags the ones that come down to how your app was built. For the wrapper-specific rejection that no-code builders hit hardest, see the companion guide on no-code app builders and App Store review.

Quick answer: The most common App Store rejection reasons in 2026, ranked by Apple's transparency data, are Performance problems (crashes, bugs, incomplete builds, dead demo accounts) under Guideline 2.1, then Legal and privacy issues under 5.1.1, then Design issues like minimum functionality (4.2) and spam (4.3), then Business rules like in-app purchase (3.1.1), then metadata mistakes (2.3). Most are preventable before you submit. A subset, like the web-wrapper and thin-app rejections, are structural: they come from how the app was built, and a genuinely native build (for iOS, a tool like Superapp that outputs native Swift) avoids them by design.

The real numbers, from Apple

Most articles rank rejection reasons by impression. Apple actually publishes the counts in its App Store transparency reporting, broken down by which section of the review guidelines a submission failed. Here is the 2025 breakdown.

Those category figures come from Apple's transparency reporting (Kickstart). They sum to more than the total number of rejected submissions because one submission can cite several guidelines, but the distribution is the useful part: Performance alone accounts for more rejections than Legal, Design, Business, and Safety put together. Apple has also said that more than 40% of unresolved review issues relate to a single guideline, 2.1 App Completeness (Choicely).

Two more numbers put this in perspective. The rejection rate actually fell year over year, from 24.85% of submissions in 2024 to 23.00% in 2025, so review is not getting harsher (Choicely). And review is fast: Apple says about 90% of submissions are reviewed in under 24 hours, so the cost of a rejection is usually days, not weeks (Kickstart). The takeaway is clear before we even get to the list: the highest-value thing you can do is submit a finished app that works on the reviewer's device.

Rejection reasons at a glance

Here is the whole list in one view, with the guideline, whether it is usually a binary problem (needs a new build) or a metadata problem (resubmit the same build), and the one-line fix.

The single most useful column is the third one. Metadata rejections let you fix a field and resubmit the same binary, while binary rejections need a new build, so knowing which kind you have tells you how fast you can be back in review.

Binary rejections versus metadata rejections

Apple distinguishes binary rejections, which are about the app's actual behavior, from metadata rejections, which are about the text and images around it. The difference matters because it dictates your recovery path. A metadata rejection (a broken URL, a mismatched screenshot, an inaccurate privacy label) is fixed by editing App Store Connect and resubmitting the same build, often the same day. A binary rejection (a crash, a missing feature, a manifest violation) needs code changes, a new build, and a bumped build number.

Counterintuitively, metadata rejections are common precisely because the binary usually works. People test their own apps, so the code is often fine, but the compliance paperwork around it is where corners get cut, and a support URL can be checked in five seconds by a reviewer (App Lander). That is good news: the most frequent first-submission rejections are also the cheapest to fix.

1. App Completeness: crashes, placeholders, and dead logins (Guideline 2.1)

This is the single biggest cause of rejection, and it is entirely self-inflicted. Guideline 2.1 covers apps that crash, contain bugs, ship with placeholder or "coming soon" content, have broken support or privacy-policy URLs, or cannot be fully tested by the reviewer (Apple). A reviewer opens your app on a real device on Apple's network, spends minutes not hours, and if the happy path breaks in that window, the review is over.

Crashes and bugs

The largest slice of the largest category. A reviewer runs your release build on current hardware and the latest OS, and if it crashes or a core feature fails, the review ends there. Most crash rejections are the app meeting real hardware for the first time, and they are often traceable to a missing config value on the production scheme. Test the actual release build on a real device, on the oldest OS version you claim to support, before you submit.

Placeholder content and unfinished builds

Any filler text, "coming soon" screen, or temporary artwork signals the app is not finished and triggers an instant rejection. Apple's own wording asks you to scrub "placeholder text, empty websites, and other temporary content" before submission (Apple). Unfinished features and test builds belong in TestFlight, not the App Store.

Dead demo accounts and login walls

If any part of your app sits behind a login and you do not provide working credentials, the reviewer physically cannot assess it, and stale demo logins are one of the most common 2.1 rejections. Provide a working demo account or a full demo mode, re-test the exact credentials on a clean install the morning you submit, and if a code is needed, paste it into the review notes rather than making the reviewer guess.

Broken links and dead backends

Reviewers click your support, marketing, and privacy-policy URLs, so a single typo or parked domain is a rejection. Just as important, review happens from Apple's network, so if your backend is asleep or IP-restricted when the reviewer opens the app, it "does not work" as far as they are concerned. Confirm every link resolves and that staging restrictions do not apply to production.

2. Minimum functionality: a website in an app (Guideline 4.2)

The headline item in the Design category, and the one that decides whether an app can exist at all. Apple requires "features, content, and UI that elevate it beyond a repackaged website," and says an app that is not "particularly useful, unique, or 'app-like'" does not belong on the store (Apple). A WebView wrapper, a thin single-screen utility, or a PDF viewer with no native interactions is the classic trigger. A related sub-code, 4.2.6, rejects apps generated from a template or app-builder service unless submitted by the provider, which is why no-code and AI-builder apps hit this line often.

The fix is to add real native functionality a website cannot offer (push notifications, offline support, device integration) or, better, to build native in the first place so the question never arises. This is a structural rejection: it comes from how the app was built, not from a metadata field. For the full playbook on which builders trigger it and how to pass, see the guide on no-code app builders and App Store review.

3. Privacy: policies, labels, and account deletion (Guideline 5.1.1)

Privacy is where enforcement has tightened hardest since 2024, and it is the bulk of the Legal category. The data collection itself is rarely the problem; the mismatch is. Apple cross-checks three artifacts, your App Privacy nutrition label, your privacy manifest, and the app's actual runtime behavior, and rejects on any disagreement (App Lander). If your label says "Data Not Collected" while an embedded SDK ships analytics, that is a rejection.

Several specific traps live here. Your privacy policy URL must be a real, current policy at a stable link, not a 404 or a marketing homepage. Every permission prompt needs a purpose string that explains why you need access in plain language, because a vague "this app uses the camera" will be flagged where "scans your paper receipts so you do not have to type them" passes (Kickstart). Since May 2024, apps using "required reason" APIs (including everyday ones like UserDefaults and file timestamps) must declare them in a PrivacyInfo.xcprivacy manifest, and a missing manifest fails the upload with error ITMS-91053 (Apple). Since February 2025, privacy-impacting third-party SDKs must ship their own manifests too, so one outdated dependency can block you (OrbitKit). And since June 30, 2022, any app that lets users create an account must let them delete it from inside the app, under Guideline 5.1.1(v) (iOS Submission Guide). Audit every SDK's data collection, reconcile all three privacy artifacts, write honest purpose strings, and ship the account-deletion flow.

4. Inaccurate metadata and screenshots (Guideline 2.3)

Metadata is judged first, costs nothing to fix, and still causes an outsized share of rejections, because a reviewer reads your name, subtitle, and screenshots before launching anything. Apple requires that all metadata "accurately reflect the app's core experience" (Apple). Screenshots that show features the app does not have, concept art or mockups, a description promising more than the build delivers, or a product page showing another platform all get flagged.

There is also a stricter sub-rule, 2.3.1, against hidden or undocumented features: any functionality not visible to the reviewer, or new features not described specifically in the review notes, is grounds for rejection, and marketing the app in a misleading way can cost your developer account (Apple). The fix is to make everything on the product page true, current, and about this app on this platform. Retake screenshots from the shipping build after any redesign, keep the app name under 30 characters, and avoid keyword stuffing in the name or subtitle, since Apple's automated review now flags title strings that read like a keyword list. Move keyword work into the dedicated keywords field, where it belongs.

5. Spam and copycats (Guideline 4.3)

Guideline 4.3 targets apps that are "indistinguishable from what's already widely available" or that spread across multiple Bundle IDs of the same app (Apple). Apple explicitly names categories like flashlight, wallpaper, and simple timers that it will no longer accept without a meaningfully different experience. The 4.3(a) variant is used when an app looks like a low-effort reskin of a template, and Apple has the common boilerplate screenshots in its review tooling (Shipnative).

The fix is real differentiation, visible not just claimed. If you built on a boilerplate or template, change the layout and flows, not only the colors, so your onboarding and paywall do not match the template's marketing site. If you serve several locations or clients, ship one app with an in-app picker rather than a family of near-identical submissions. The November 2025 revision also strengthened copycat protection, so you cannot use another developer's icon, brand, or product name without approval (Push My App).

6. In-app purchase and payments (Guideline 3.1.1)

A common Business-category rejection: an app that sells digital goods or subscriptions but routes users to an external website to pay, or shows a "buy on our site" link. Apple requires digital purchases to go through its in-app purchase system in most cases, and a link out to bypass it is a rejection (Shotlingo). The fix is to remove external purchase links for digital goods and wire purchases through StoreKit, and to make sure any configured in-app purchases are complete, visible, and functional for the reviewer, with an explanation in the review notes if they are hard to find. A subscription paywall should also clearly show the price and what is included before purchase.

7. Design quality (Guideline 4.0)

Guideline 4.0 covers design quality independent of functionality: broken layouts, typos, dark-mode failures, overlapping elements, or an interface that does not follow platform conventions can read as low quality even when nothing is technically broken. This is a judgment call, and it correlates with how native the app feels; a wrapped or generic template app is more likely to be read as low effort. Following Apple's Human Interface Guidelines and testing your layout across device sizes and both appearance modes clears most of this.

8. Technical and binary gotchas

Beyond the headline reasons, several binary-level issues reject apps at or near upload, often before a human even opens them. As of April 2026, every upload must be built with the current Xcode and iOS SDK, so a build made with an outdated toolchain is refused at upload (Push My App). Static analysis rejects binaries that reference private APIs under Guideline 2.5.1, which often come from an outdated dependency (Push My App). Encryption export compliance trips up many apps: if the ITSAppUsesNonExemptEncryption key is missing from Info.plist, every submission keeps asking, and answering wrong can hold up review (Push My App). And orphaned entitlements, declaring HealthKit, Push, or Wallet capabilities the app never uses, get flagged by privacy review (Push My App). These are the kind of issues that a current, cleanly built native app avoids and that stitched-together or outdated builds keep hitting.

The timeline of new requirements

Part of why apps get rejected is that Apple keeps adding requirements, and builds made before a given date often miss the new one. Here is the recent timeline.

Requirement dates are drawn from Apple's documentation and current submission guides (Apple, OrbitKit, Push My App). The pattern across all of them is that Apple keeps raising the bar, and a build made with current tools absorbs each change more easily than an old or wrapped one.

Where the build itself is the problem

Most rejections on this list are fixable in App Store Connect or with a config change, but a few are structural, meaning they come from how the app was built and cannot be patched with metadata. The web-wrapper and thin-app rejection (4.2), the template rejection (4.2.6), design-quality issues from a non-native feel (4.0), crashes from an unstable framework (2.1), and privacy-manifest or stale-SDK failures all trace back to the underlying build. This is where the choice of tool matters, and where a genuinely native build has a structural advantage.

Superapp generates a real native iOS app in Swift, built with current Apple tooling, so the structural rejections above are avoided by construction rather than fixed after the fact. It does not exempt you from the metadata, privacy, and payment rules, which are yours to get right regardless of how you build, but it removes an entire class of rejection that wrapped and outdated apps keep hitting. For the deeper version of this argument, see the guide on no-code app builders and App Store review.

How to read a rejection email

The rejection notice is more informative than it first looks, and reading it precisely saves a wasted resubmission. Apple names the exact guideline number, which tells you the category and often the fix: a 2.1 means completeness (test the build, check the demo account), a 5.1.1 means privacy (reconcile your label and manifest), a 4.2 means minimum functionality (add native value). For a crash, the message names the specific device model and OS build the reviewer used, which is where you should reproduce it rather than on whatever hardware you happen to own. Sub-codes matter too: a 4.2.6 is a template rejection asking you to prove the app is custom, while a 4.2.3 points at web content being the primary feature.

Apple also sometimes layers rejections, citing more than one guideline at once, so read the whole message rather than fixing only the first item. And because the notes stay attached to the app across reviewer rotations, addressing every cited point in one pass is faster than a series of partial fixes. If the message is genuinely unclear, you can ask for clarification in the Resolution Center instead of guessing.

Myths about App Store rejection rates

A few widely repeated claims are worth correcting, because they cause needless panic. The most common is that 40% to 60% of first submissions are rejected; that figure has no traceable source (Choicely). The real, published number is that about 23% of submissions were rejected in 2025, and that counts submissions rather than apps, since one app is often submitted several times before approval (Choicely). The true first-submission approval picture is better than the scary version implies.

A second myth is that review is getting harsher. In fact the rejection rate fell from 24.85% in 2024 to 23.00% in 2025, and hundreds of thousands of initially rejected submissions go on to be approved after a fix (Choicely). A third is that rejections are arbitrary. The category data shows the opposite: they cluster heavily around completeness and performance, which are exactly the things you can test before submitting. Treat rejection as a predictable, mostly preventable checkpoint, not a lottery.

What to do when your app is rejected

A rejection is a step in the process, not the end of it, and the data backs that up: 387,087 submissions were approved in 2025 after an earlier rejection (Choicely). The first move is to read the rejection message carefully, because Apple names the exact guideline and often the specific problem, including the device and OS build for a crash. Reproduce the issue on that configuration before you respond.

Then choose the right path. If the reviewer is simply wrong or missed something, reply in the Resolution Center with specifics, pointing to where the functionality lives and, if useful, attaching a short screen recording, rather than resubmitting blindly. If the reviewer is right, make the change: fix the code and upload a new build for a binary issue, or edit the field and resubmit the same build for a metadata issue. Do not resubmit the same build with no changes, because the rejection notes follow the app even as reviewers rotate. And do not argue legality or beg; reviewers respond to specific evidence about user-facing functionality, not to appeals about effort.

A pre-submission checklist

Because most rejections are preventable, a short checklist before you hit Submit catches the majority. Test the release build on a real device on your oldest supported OS, and confirm no crashes in the main flows. Scrub all placeholder content and click every URL in your metadata. Provide a working demo account and re-test it the morning of submission. Reconcile your App Privacy label with your privacy manifest and actual SDK behavior, write clear permission purpose strings, and confirm the in-app account-deletion flow works if you support accounts. Make sure screenshots show the current build and the name and subtitle are not keyword-stuffed. Confirm digital purchases go through in-app purchase, set the encryption compliance key, and build with the current SDK. Run through those and you are ahead of most of the queue.

The bottom line

The most common App Store rejection reasons in 2026 are led by Performance and completeness problems, not policy disputes, and the majority are self-inflicted and fixable before you submit. Apple's own data shows that a rejection is usually a round trip, with hundreds of thousands of submissions approved after a fix. Handle the boring compliance items (a working build, honest metadata, reconciled privacy, in-app payments) and you clear most of the list. For the structural rejections that depend on how the app was built, the surest path is a genuinely native app made with current tooling, which sidesteps the wrapper, template, and stale-SDK rejections entirely.

Frequently asked questions

What is the most common reason apps get rejected from the App Store?

App completeness under Guideline 2.1, which covers crashes, bugs, placeholder content, broken links, and dead demo accounts. In Apple's 2025 data, Performance issues caused 1,354,418 rejections, more than Legal, Design, Business, and Safety combined, and Apple says over 40% of unresolved review issues relate to Guideline 2.1 (Choicely). The most common cause of rejection is simply that the app did not work properly when the reviewer opened it.

What percentage of App Store submissions get rejected?

About 23% of submissions were rejected in 2025: Apple reviewed 9,100,620 and rejected 2,093,244, down from 24.85% in 2024 (Choicely). Note that this counts submissions, not apps, and one app is often submitted several times before approval, so it is not a first-submission failure rate. In 2025, 387,087 rejected submissions were approved after a fix.

Is an App Store rejection permanent?

No. A rejection is normally a round trip, not a verdict. Apple approved 387,087 submissions in 2025 that had been rejected earlier (Choicely). Most rejections point to a specific fixable issue: a crash, a broken link, a privacy mismatch, or a missing feature. Address the cited guideline, bump the build if needed, and resubmit.

What is the difference between a binary and a metadata rejection?

A metadata rejection is about the text and images around your app (a broken URL, a mismatched screenshot, an inaccurate privacy label), and you fix it by editing App Store Connect and resubmitting the same build. A binary rejection is about the app's behavior (a crash, a missing feature, a manifest violation) and needs code changes and a new build. Metadata rejections are more common because the binary usually works but the compliance paperwork gets cut corners (App Lander).

Why do apps get rejected under Guideline 4.2?

Because they do not do enough beyond a website. Guideline 4.2, Minimum Functionality, rejects web-wrapper apps, thin single-screen utilities, and template apps that Apple judges not "app-like" (Apple). It is a structural rejection tied to how the app was built, and the fix is real native functionality or a native build from the start. See the companion guide on no-code app builders and App Store review for the full breakdown.

Do I need an in-app account deletion feature?

Yes, if your app lets users create an account. Since June 30, 2022, Guideline 5.1.1(v) requires apps that support account creation to let users initiate deletion from within the app, not just on a website (iOS Submission Guide). Missing account deletion is a frequent privacy-category rejection and an easy one to prevent.

What is a privacy manifest and do I need one?

A privacy manifest is a PrivacyInfo.xcprivacy file that declares why your app uses "required reason" APIs like UserDefaults or file timestamps. Since May 1, 2024, a missing manifest fails the upload with error ITMS-91053, and since February 12, 2025, privacy-impacting third-party SDKs must ship their own manifests too (Apple, OrbitKit). If your app or any dependency touches those APIs, you need it.

What are the newest App Store requirements in 2026?

The November 13, 2025 revision added several: disclosure and permission before sharing personal data with third-party AI, stronger copycat protections, a loan-app APR cap, and coverage of HTML5 mini-apps (Push My App). Technically, every upload since April 2026 must be built with the current Xcode and iOS SDK, and iOS 26.2 introduced age-assurance frameworks (Apple). Building with current tooling keeps you aligned with these.

How long does App Store review take, and how fast can I resubmit?

Apple says about 90% of submissions are reviewed in under 24 hours (Kickstart). If you get a metadata rejection you can often fix the field and resubmit the same build the same day; a binary rejection requires a new build, so it takes as long as your fix plus another review cycle. Responding quickly in the Resolution Center keeps the app "in motion" rather than sitting idle.

How can I avoid getting my app rejected?

Submit a finished app and handle the compliance basics. Test the release build on a real device, scrub placeholder content, click every metadata URL, provide a working demo account, reconcile your privacy label with your manifest and SDK behavior, include in-app account deletion, keep screenshots current, route digital purchases through in-app purchase, and build with the current SDK. Most rejections come from this short list, so clearing it puts you ahead of most submissions.

Does the tool I build with affect my rejection risk?

For a subset of reasons, yes. Structural rejections (minimum functionality, template apps, non-native design, crashes from an unstable framework, privacy-manifest and stale-SDK failures) come from how the app was built. A genuinely native app built with current tooling, such as one produced by an AI native builder like Superapp for iOS, avoids that whole class of rejection. The metadata, privacy, and payment rules still apply regardless of build method.

Which rejection reasons come from how the app was built?

The structural ones: minimum functionality (4.2) and template rejections (4.2.6) from web wrappers, design-quality issues (4.0) from a non-native feel, crashes (2.1) from an unstable framework, and privacy-manifest or stale-SDK failures. These cannot be fixed with a metadata edit. A genuinely native app built with current tooling avoids this whole class of rejection, while the metadata, privacy, and payment rules remain yours to satisfy regardless of build method.