Apple App Store Rejection Reasons in 2026 (and How to Fix Them)

Apple reviewed 9,100,620 app submissions in 2025 and rejected 2,093,244 of them, about 23%, according to its 2025 App Store Transparency Report. The most common reason, by a wide margin, is Performance: apps that crash, are unfinished, or don’t match their own App Store listing.

Most rejections are avoidable. Below are the reasons Apple gives, in the order Apple’s own numbers rank them, with what triggers each one and how to fix it.

What Apple’s 2025 numbers show

Apple groups rejections by the section of the App Review Guidelines an app broke:

Guideline section	What it covers	Rejections in 2025
Performance (2)	Crashes, unfinished apps, inaccurate metadata	1,354,418
Legal (5)	Privacy, data collection, intellectual property	495,673
Design (4)	Minimum functionality, spam, copycat apps	415,532
Business (3)	In-app purchase and payment rules	283,820
Safety (1)	Objectionable and user-generated content	151,159
Other		4,145

One submission can break more than one guideline, so these add up to more than the 2,093,244 total. Even so, Performance rejections outnumber the other five categories combined, if only just. Privacy has no category of its own in Apple’s report; it sits under Legal.

1. Performance: the app is unfinished, unstable or mislabelled

Guideline 2 is where most apps fail, and it’s the most fixable.

What triggers it:

• Crashes and bugs. App Review installs your app on real devices. If it crashes on launch, freezes, or a core feature doesn’t work, it’s rejected.
• Unfinished submissions. Guideline 2.1(a) asks for final versions: “placeholder text, empty websites, and other temporary content should be scrubbed before submission.” Broken links count.
• No way in. If your app has a login, Apple needs a demo account, and your backend has to be live during review. A reviewer who can’t sign in can’t approve you.
• A listing that doesn’t match the app. Guideline 2.3 requires your description, screenshots and previews to reflect the app’s core experience. Screenshots must “show the app in use, and not merely the title art, login page, or splash screen.”

How to fix it:

• Test on a physical device running the oldest iOS version you support, not only in the simulator.
• On a clean install, tap every link and every button.
• Put working demo account details in the App Review Information notes, and keep your servers up until review finishes.
• Take screenshots of real screens. Our guide to App Store screenshots covers what converts as well as what passes.

2. Legal: privacy and intellectual property

What triggers it:

• A privacy policy in only one place. Guideline 5.1.1(i) requires a link to your privacy policy both in your App Store Connect metadata and inside the app, somewhere easy to find.
• No in-app account deletion. If your app supports account creation, Guideline 5.1.1(v) requires you to offer account deletion inside the app. This one is easy to miss, because many websites handle deletion by email.
• Forcing a login for no reason. The same guideline says that if your app doesn’t include significant account-based features, people should be able to use it without logging in.
• Asking for data you don’t need. Apps may not require personal information unless it’s directly relevant to the app’s core function or required by law.
• Sharing data without permission. Guideline 5.1.2(i) prohibits using or sharing someone’s personal data without first getting their permission, unless the law allows it.
• Privacy labels that don’t match reality, including the data your third-party SDKs collect. More on that in our privacy labels guide.
• Content you don’t own. Guideline 5.2 requires that your app only contain content you created or have a license to use, including trademarks and images.

How to fix it:

• Link your privacy policy from App Store Connect and from a settings or profile screen in the app.
• If users can sign up, add a delete-account option inside the app.
• List every SDK in your app and check what each one collects before you fill in your privacy labels.
• Request permissions at the moment they’re needed, with a purpose string that explains why.

3. Design: more than a repackaged website

If your app started life as a website, this is the section to read carefully.

Guideline 4.2 says: “Your app should include features, content, and UI that elevate it beyond a repackaged website.” It adds that apps shouldn’t primarily be “marketing materials, advertisements, web clippings, content aggregators, or a collection of links.”

A web view that loads your site and does nothing else is exactly what 4.2 is written to reject. What gets an app over the line is behaviour a browser tab doesn’t offer: push notifications, native navigation such as a bottom tab bar, offline access, deep links that open the right screen, and in-app purchase where it applies.

To be clear about the limits: Apple doesn’t publish a checklist, so no set number of native features guarantees approval. The reviewer is judging whether the app is worth installing over the website.

Guideline 4.3 covers spam. Don’t submit several near-identical apps under different bundle IDs, such as one per city or per store location, and don’t submit apps “indistinguishable from what’s already widely available.”

If you built with an AI builder like Lovable, Bolt or Replit, we cover the specific traps in getting AI-built apps approved.

4. Business: payments and in-app purchase

Guideline 3.1.1 says that if you unlock features or functionality inside your app, such as subscriptions, premium content or a full version, you must use Apple’s in-app purchase.

Physical goods and services used outside the app are different. An online store selling clothes, or an app booking a haircut, uses its own checkout, not in-app purchase.

What changed in 2025: after a US court ruling in Epic Games v. Apple, Apple updated its guidelines in May 2025. Apps on the United States storefront can now include buttons, links and other calls to action pointing to purchase options outside the app, without a special entitlement. Outside the US, those links are still not allowed unless you hold the entitlement for that region and the region permits it. Apple has appealed the ruling, so check the current guideline before you build your pricing around it.

We go deeper in external payment links on iOS and in-app purchase compliance.

5. Safety: content and user-generated content

Guideline 1 covers objectionable content. The rule that catches most apps is 1.2: if users can post content, your app must include all four of:

• A way to filter objectionable material before it’s posted
• A way to report offensive content, with timely responses
• The ability to block abusive users
• Published contact information so users can reach you

A community feature, review section or chat without these will be rejected even if nobody has posted anything objectionable yet.

Before you submit

• Tested on a real device, every link works, no placeholder content
• Demo account in the review notes, backend live
• Screenshots show real screens, not splash or login
• Privacy policy linked in App Store Connect and inside the app
• In-app account deletion, if users can create accounts
• Privacy labels cover every SDK
• Native features beyond what the website does
• Digital purchases go through in-app purchase, unless the US storefront rules apply
• Filtering, reporting, blocking and contact details, if users can post content

The full version is in our App Store review checklist.

If your app is rejected anyway

1. Read the guideline number. The rejection message names the exact rule, which tells you what to change.
2. Reply if the reviewer missed something. If they couldn’t sign in or couldn’t find a feature, reply to App Review in App Store Connect with the details. That is often all it takes.
3. Appeal if you think the decision is wrong. Apple’s App Review Board hears appeals, but most rejections are resolved by changing the app, not by arguing.
4. Fix and resubmit. Change only what the rejection asked for, so you don’t introduce a new problem on the second pass.

How Twinr handles this

We turn your existing website into native iOS and Android apps, and we handle App Store submission ourselves. If Apple pushes back, that’s our problem to fix, not yours, which is why we offer an approval guarantee.

The features that answer the guidelines above are built in:

• Guideline 4.2: push notifications, native navigation, offline browsing, deep links and native screens, so your app does things your website can’t.
• Guideline 5.1.1(v): an Account Delete extension your website can trigger with a single JavaScript bridge call, so deletion happens inside the app.
• Guideline 3.1.1: native Apple in-app purchase for digital goods and subscriptions, set up without code.

What we can’t do is give an app a reason to exist. If your website offers nothing people would come back for, a tab bar won’t change Apple’s mind, and it shouldn’t.

If you’re ready to ship, Get Started and we’ll take it through review with you.