# Why Apple rejects apps and how to avoid it: the guideline numbers that matter

> Most App Store rejections come from guideline 2.1: crashes, placeholder content, broken links or a missing demo account. Here are the common reasons, 4.3 spam and 4.2.6 templates, and a checklist.

Published 2026-11-02 by ODEL.

Apple rejects most apps for ordinary reasons, not exotic ones: the app crashes, has placeholder content, broken support or privacy links, or the reviewer cannot sign in. Apple says over 40 percent of unresolved issues relate to guideline 2.1, App Completeness ([Apple, App Review](https://developer.apple.com/distribute/app-review/)). Fix those, add accurate privacy answers, and avoid spam-like duplicates (4.3) and template apps (4.2.6), and most rejections never happen.

## How often apps get rejected

Apple's 2024 App Store transparency report, as reported by MacRumors, counted 7,771,599 app submissions and 1,931,400 rejections, with 295,109 apps approved after the developer revised them ([MacRumors, May 2025](https://www.macrumors.com/2025/05/30/app-store-2024-transparency-report/)). In other words, rejection is common and usually fixable.

Review itself is fast: Apple says it typically reviews at least 50 percent of submissions in under 24 hours and 90 percent in under 48 hours ([Apple, App Review](https://developer.apple.com/distribute/app-review/)). The delay comes from back-and-forth after a rejection, so getting it right the first time saves days.

The rules live in the [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/), last updated October 16, 2026. Guideline numbers below refer to that document.

## The common rejection reasons, by guideline

Apple lists these as the most common issues ([Apple, App Review](https://developer.apple.com/distribute/app-review/)):

| Guideline | What goes wrong | How to avoid it |
|---|---|---|
| 2.1 App Completeness | Crashes and bugs | Test the exact build you submit on a real device and the latest iOS |
| 2.1 | Placeholder content | Remove "lorem ipsum", test data, empty screens and "coming soon" buttons |
| 2.1 | Incomplete information | Give a working demo account and notes for any feature behind login or hardware |
| 2.1, 5.1 | Broken links | Support URL and privacy policy URL must load; both are required for every app |
| 5.1 | Privacy policy issues | Policy must match what the app and its SDKs actually collect |
| 5.1.1 | Unclear data access requests | Permission prompts (purpose strings) must say why the app needs camera, location or photos |
| 2.3 | Inaccurate screenshots, misleading users | Screenshots and description show the real app, no features it lacks |
| 4.2 | Not enough lasting value, web clippings, link collections | The app must do more than show a website |
| 4.3 | Repeated submission of similar apps | One app with options, not many near-copies |
| 4.1 | Copycats | No borrowed names, icons or UI from other apps |
| 3, 5.1.1 | Submitted by incorrect entity | Banking, crypto, healthcare, gambling and air travel apps must come from the legal entity offering the service |

Two more that catch first-time founders:

- **5.1.1(v) account deletion.** If the app lets people create an account, it must also let them delete it inside the app ([Apple, account deletion](https://developer.apple.com/support/offering-account-deletion-in-your-app/)).
- **3.1.1 in-app purchase.** Digital content and subscriptions unlocked inside the app must use Apple's in-app purchase, with clear prices, terms and a restore option ([App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)).

## 4.3 spam: why near-identical apps get blocked

Guideline 4.3 targets spam. Its first part, 4.3(a), says not to create multiple bundle IDs of the same app; if you need versions for different cities, teams or clients, ship one app and handle the differences inside it. Its second part, 4.3(b), warns against piling on to saturated categories with nothing new ([App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)).

Where it bites clients: an agency that reuses one codebase for many customers, under one developer account, can trigger 4.3 for all of them. A reviewer may also compare your app with others from the same account. The fix is a distinct product with its own features, published under your own developer account.

## 4.2.6 template apps: who is allowed to submit

Guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content ([App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)). In practice:

- A restaurant can publish an app built on a template platform, under the restaurant's own account.
- An agency cannot publish dozens of template apps for different restaurants under the agency's account.

This is one more reason your app should be published under your company's developer account. See [setting up Apple and Google developer accounts for your company](/blog/set-up-apple-and-google-developer-accounts-for-your-company) and [who owns your app code and developer accounts](/blog/who-owns-your-app-code-and-developer-accounts).

## Pre-submission checklist

Run this before every submission, not only the first one:

1. Install the release build (not a debug build) on a real iPhone and click every button.
2. Search the app and metadata for placeholder text, test accounts and "beta".
3. Create a demo account with sample data and paste its credentials in App Review notes.
4. Open the support URL and privacy policy URL from the App Store Connect fields.
5. Check that every permission prompt explains the reason in plain words.
6. Fill in App Privacy details for your app and every SDK, and include SDK privacy manifests ([Apple, App Privacy details](https://developer.apple.com/app-store/app-privacy-details/)).
7. Test purchases in the sandbox: buy, cancel, restore. Make sure every product shown on the paywall exists and is submitted with the build.
8. Confirm account deletion works if the app has accounts.
9. Compare screenshots with the current build.
10. If the app is in a regulated field, confirm the developer account belongs to the regulated entity.

## If you are rejected anyway

- Read the message in App Store Connect carefully: it names the guideline. Reply in the same thread with a clear explanation or a screen recording if the reviewer missed something.
- Fix and resubmit for real problems. Do not argue about crashes.
- If you believe the decision is wrong, you can appeal to the App Review Board ([Apple, appeals](https://developer.apple.com/contact/app-store/?topic=appeal)).
- Never resubmit the same app under a new bundle ID to get around a rejection. That is exactly what 4.3 is for.

## How ODEL handles App Review

ODEL publishes and updates its own live iPhone and Android apps, including subscription apps such as [ChairBook](/app/chairbook) and [BidCraft](/app/bidcraft), so App Review notes, paywall checks and privacy labels are routine work. Before each client submission ODEL runs a written checklist like the one above, including a check that the app is distinct from anything else on the same account.

## When ODEL fits, and when it does not

ODEL fits if your app has been rejected and you need someone to find the cause, fix it and resubmit, or if you want a launch done right the first time: see [app rescue and maintenance](/services/app-rescue-and-maintenance) and [App Store launch and ASO](/services/app-store-launch-and-aso).

ODEL is not the right fit for:

- getting a template or reskinned app approved under someone else's account (it will not be),
- apps in regulated fields where the legal entity is not ready to own the developer account,
- legal disputes with Apple, where you need a lawyer.

If your app is stuck in review, [describe the rejection](/services#start) and ODEL will tell you what it would take to fix.