The App Store rejection reasons that trip up most submissions in 2026

Most App Store rejections trace back to six guidelines. Five of the six are fixable before you ever submit. Apple's own guidance says that over 40% of unresolved review issues come from a single completeness rule, so a short checklist against these six catches most problems before a reviewer ever sees your build.

Crashes, bugs and incomplete builds (2.1)

Guideline 2.1, App Completeness, is the one to fix first. Apple's text is direct: submissions "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission", and apps should be "tested on-device for bugs and stability" before submission, with demo account info included and the backend service turned on if the app includes a login.

That breaks down into three things in practice. Test the exact build you're submitting on a device running the current OS, not a simulator on last year's release. Remove every placeholder image, lorem ipsum string and "coming soon" screen. And if any part of the app sits behind a login, ship working demo credentials and leave the backend live for the review window. A reviewer who can't log in can't approve the rest of the app either.

Apple also confirms that 90% of submissions get a decision in under 24 hours, and that incomplete submissions are the main reason a review runs longer. This is exactly what the testing pass we run before every SwiftUI release is built to catch, before it costs a submission cycle. The same discipline matters during a Swift 6 concurrency migration, where a build that compiles cleanly can still crash at runtime on a device the simulator never exercised.

Vague or missing Notes for Review (2.3.1)

Guideline 2.3.1 requires specificity, not just accuracy. Apple's wording: apps must not include "any hidden, dormant, or undocumented features," and "all new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected)".

A Notes for Review entry that says "bug fixes and improvements" tells a reviewer nothing. A useful one names the exact feature, explains why it exists, and states what a reviewer needs to do to see it work, for example which menu exposes a beta flag, or which account tier surfaces a paywalled screen. If a feature depends on a server flag or a specific region, say so in the same field.

Not enough app to justify the App Store (4.2)

Guideline 4.2, Minimum Functionality, filters out apps that don't do more than a website already does. Apple's language: an app "should include features, content, and UI that elevate it beyond a repackaged website," and, other than catalogs, apps "shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

Here's the line Apple actually draws: an app that uses native capability, offline access, push notifications, device sensors, versus one that's a browser wrapper around a marketing site with a few extra buttons. If your app's only reason to exist on a phone is convenience, that's usually not enough on its own.

Repackaged, templated or spam submissions (4.3)

Guideline 4.3, Design: Spam, targets apps built from the same source or assets as an app already on the Store with "only minor differences," including apps built on a purchased or repackaged template with cosmetic changes only, and multiple similar apps submitted across accounts.

Apple names a few categories it treats as saturated on sight: astrology, horoscope, palm-reading and similar biometric fortune-telling apps, regardless of build quality. If your product sits in a crowded template category, the fix isn't a stronger appeal. It's shipping content and functionality that's genuinely yours.

Privacy policy gaps and undisclosed data collection (5.1.1)

Guideline 5.1.1 requires a privacy policy that does real work, not a boilerplate page. It must identify what data the app collects and how, describe all uses of that data, confirm that any third party handling the data provides equal protection, and explain retention, deletion and how a user revokes consent. Guideline 5.1.1(ii) goes further: consent is required for collecting usage data even when that data is anonymous at the point of collection.

Before you submit, read your own privacy policy against that list line by line. A generic template that never names your analytics SDK or your ad network won't pass. A data collection permission prompt with no purpose string in Info.plist is an easy, avoidable rejection under the same guideline.

Gating content outside in-app purchase (3.1.1)

Guideline 3.1.1 is narrow and absolute: subscriptions, in-game currency, game levels, premium content and full-version access must all go through in-app purchase, and apps can't substitute their own mechanism, license keys, QR codes, AR markers or cryptocurrency wallets among the named examples Apple rejects.

If your monetization plan routes around Apple's payment system for anything gated inside the app, expect a rejection under this guideline, no matter how the feature is framed. In-app currencies also can't expire, and any restorable purchase needs a working restore mechanism.

How to prioritize before you submit

Work in this order. Fix 2.1 first, since it accounts for the largest share of unresolved rejections and is entirely within your control: test on-device, remove placeholders, ship a working demo account. Next, write specific Notes for Review entries for anything new or non-obvious. Then check your privacy policy against the 5.1.1 checklist line by line. Only after those three should you worry about 4.2 positioning, 4.3 originality and 3.1.1 monetization mechanics. Those usually surface as design decisions made long before submission, not last-minute fixes.

Given that most reviews resolve in under 24 hours, a clean first submission is almost always faster than fixing and appealing after a rejection. Five of the six categories above are checklist items, not judgment calls, and the other two, 4.2 and 4.3, come down to whether the app earns its place on the Store on its own merits. It's the same compliance gate we run before every App Store submission, applied before a build ever reaches App Store Connect. If you want a second set of eyes on a submission before you send it, we can help.

Frequently asked questions

What is the most common reason apps get rejected?

Guideline 2.1, App Completeness. Apple attributes over 40% of unresolved rejections to it: crashes, incomplete builds, placeholder content, broken links, and login-gated features with no working demo account.

How long does App Store review actually take?

Apple reports that 90% of submissions get a decision in under 24 hours. Incomplete submissions, meaning missing demo credentials or unclear Notes for Review, are the main cause of delay past that window.

Can I appeal an App Store rejection?

Yes, one appeal per rejected submission through the Submit an Appeal form. Apple expects you to first respond to any additional information the reviewer requested, and to state specifically why the app complies with the guideline cited.

Does a repackaged website qualify as an app?

Not under Guideline 4.2, Minimum Functionality. Apple rejects apps that are primarily marketing material, a content aggregator, or a thin wrapper around a website with no app-specific utility.

What has to be in an App Store privacy policy?

Under Guideline 5.1.1 it must state what data the app collects and how, all uses of that data, that any third party handling it provides equal protection, and how a user can revoke consent or request deletion.