Haplo
Build log Browse the apps

Apple Rejects Nearly 1 in 4 App Submissions. Here's Why

In 2025, App Review turned down 2,093,244 of the 9,100,620 app submissions it reviewed. Here's what Apple's rules say about the reasons that come up most, and how to clear review the first time.

Haplo 11 min read

A red and white barrier lowered across a road at a railway level crossing, with a red and white St Andrew's cross sign on the right and low industrial buildings behind
A lowered barrier at a level crossing in Hirschaid, Germany · Photo: Reinhold Möller, CC BY-SA 4.0 (Cropped and resized)

Apple says every app on the App Store is “reviewed by experts”, and those experts say no a lot. In 2025, App Review turned down 2,093,244 of the 9,100,620 app submissions it reviewed, according to Apple’s 2025 App Store Transparency Report. That’s 23 percent, or nearly 1 in 4.

The reassuring part is where the rejections come from. The performance rules, on crashes, placeholder content, missing demo accounts and inaccurate metadata, were cited more than every other section combined, and those are problems you can catch yourself.

We make ShipHappens, the Mac app we use to lay out, translate and upload the App Store listings for our own nine apps. This guide covers the most common App Store rejection reasons, what Apple’s rules say about each, how to avoid them, and what to do if you’re rejected anyway. We checked everything against Apple’s pages in September 2026.

How often does Apple reject apps?

The report counts submissions, not apps, and Apple notes that an app may be submitted several times before it’s approved. Here are the last two years, from the 2025 report and the 2024 report:

Figure 2024 2025
Submissions reviewed 7,771,599 9,100,620
Submissions rejected 1,931,400 2,093,244
Share rejected 24.9% 23.0%
Approved after rejection 295,109 387,087

And the 2025 rejections by section of the App Review Guidelines:

Section What it covers Rejections
1. Safety Objectionable and user-generated content, kids, physical harm, data security 151,159
2. Performance App completeness, beta testing, accurate metadata, hardware and software requirements 1,354,418
3. Business Payments, in-app purchase, subscriptions 283,820
4. Design Copycats, minimum functionality, spam, login services and more 415,532
5. Legal Privacy, intellectual property, gambling, VPNs, developer code of conduct 495,673
Other 4,145

One submission can break several guidelines, so the sections add up to more than the rejected total. Even so, Performance was cited just more than all the other sections put together (1,350,329), and Apple’s App Review page goes further: “On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness.”

The most common App Store rejection reasons

These follow the report’s biggest sections. Apple says a rejection’s details include “any specific App Review Guidelines that your submission didn’t follow”, so each heading gives the number you’ll see.

1. Crashes, bugs and placeholder content (Guideline 2.1)

Guideline 2.1(a) wants “final versions with all necessary metadata and fully functional URLs included”, with placeholder text “scrubbed before submission”, and warns: “We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.” Apple’s list of common issues adds broken links. Every app needs working links to user support and a privacy policy, and App Store Connect Help says the support URL “must lead to actual contact information”.

To avoid it, install the release build through TestFlight and test it on a device running the latest OS, as Apple asks. Hunt for lorem ipsum, “coming soon”, test data and dead buttons, and tap every link. If your iPhone app runs on iPad, which Guideline 2.4.1 encourages, try it there. Mac apps also face 2.4.5: they must be sandboxed, can’t run code at login without consent or ask for root, and must update through the Mac App Store.

2. The reviewer can’t get in (Guideline 2.1)

The same guideline says to “include demo account info (and turn on your back-end service!) if your app includes a login.” A built-in demo mode can replace the account only when legal or security obligations rule one out, and only with Apple’s prior approval.

These details go in the App Review Information section of App Store Connect, which customers never see. The demo account “must not expire”, and the Notes field holds up to 4,000 bytes, in any language. Guideline 2.3.1(a) adds that new features and changes “must be described with specificity” there, because “generic descriptions will be rejected”.

We’d set up a review account that never expires, with realistic data and no sign-in code sent to someone’s phone. Then write notes a stranger could follow: how to reach each feature that isn’t obvious, what changed, and where every in-app purchase lives. Keep your servers up until the review is over, too. A backend that’s down looks exactly like a broken app.

3. In-app purchases the reviewer can’t find (Guideline 2.1(b))

Guideline 2.1(b) reads in full: “If you offer in-app purchases in your app, make sure they are complete, up-to-date, visible to the reviewer and functional. If any configured in-app purchase items cannot be found or reviewed in your app, explain the reason in your review notes.”

Three ways purchases go missing:

  • Left out of the submission. The first in-app purchase of each type “must be submitted with a new app version”, says App Store Connect Help.
  • A paywall that fails quietly. If products don’t load, show an error, a way to try again and a Restore button. A spinner that never ends looks like a missing purchase.
  • Grandfathering that catches the reviewer. Guideline 3.1.2 says an app moving to subscriptions “should not take away the primary functionality existing users have already paid for”, and one way to honour that is to unlock everything for anyone who installed before a cutoff date. The trap: Apple’s receipt documentation says to use the sandbox “while your app is in review”, and in the sandbox the original purchase date “is always 2013-08-01 12 AM PDT”, while the original app version is always “1.0”. A cutoff check hands the reviewer the full app with nothing to buy. Check the app transaction’s environment and only grandfather production transactions.

Before you submit, buy every product as a brand new customer in the sandbox, which uses your real product information from App Store Connect.

4. Screenshots and metadata that don’t match the app (Guideline 2.3)

Your metadata, “including privacy information, your app description, screenshots, and previews”, must “accurately reflect the app’s core experience”. The rules that catch people:

  • Screenshots should “show the app in use, and not merely the title art, login page, or splash screen” (2.3.3), and match “the corresponding device type in App Store Connect.” Our App Store screenshot sizes guide has the sizes.
  • The name is capped at 30 characters (2.3.7), and no metadata may be packed “with trademarked terms, popular app names, pricing information, or other irrelevant phrases just to game the system.” Subtitles can’t “make unverifiable product claims.” More in how App Store keywords actually work.
  • No other platforms: leave out “names, icons, or imagery of other mobile platforms” (2.3.10). Icons, screenshots and previews must fit a 4+ age rating even if the app is rated higher (2.3.8).
  • What’s New must list significant changes (2.3.12), and age rating answers must be honest (2.3.6).

The same rules apply in every language you localize your listing into. If the metadata is the only problem, the status is Metadata Rejected, and Apple’s instruction is to “edit the metadata to resolve the issue, and reply to the message from App Review.”

5. Privacy policies, purpose strings and account deletion (Guideline 5.1)

Legal drew the second most rejections in 2025, and privacy comes first in it:

  • A privacy policy in two places: a link “in the App Store Connect metadata field and within the app in an easily accessible manner” (5.1.1(i)). It must say what you collect and how you use it, confirm that anyone you share data with protects it equally, and explain retention, deletion and how to withdraw consent.
  • Purpose strings that explain themselves. The reason your app gives when it asks for, say, the camera must “clearly and completely describe your use of the data” (5.1.1(ii)). Apple suggests including an example.
  • Only what you need: request only data “relevant to the core functionality of the app” (5.1.1(iii)), and never trick or force people into unnecessary access (5.1.1(iv)).
  • Account deletion. If your app supports account creation, it “must also offer account deletion within the app” (5.1.1(v)). Apple’s account deletion guidance says deactivating isn’t enough, and outside highly regulated industries you can’t make people phone or email you to finish. If your app has no significant account-based features, don’t require a login at all.
  • An equivalent login (4.8). If a third-party or social login sets up the main account, also offer one that limits data collection to name and email address, lets people keep their email private, and doesn’t collect their interactions with your app for advertising without consent.

One easy miss: code in your packages and SDKs counts as yours. The guidelines make you responsible for “third-party SDKs”, and Apple requires a purpose string when “your app’s code references” an API that touches sensitive user data. If a shared library references HealthKit and your app never uses it, remove that code rather than declaring access you don’t need. Guideline 2.5.1 says HealthKit “should be used for health and fitness purposes and integrate with the Health app.”

6. Paying outside in-app purchase (Guideline 3.1)

Under 3.1.1, if you unlock features or content, “you must use in-app purchase”, and apps “may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets”. You also need “a restore mechanism for any restorable in-app purchases.”

Linking out to pay depends on the storefront. As of September 2026, apps on the United States storefront don’t need an entitlement for “buttons, external links, or other calls to action” pointing to other ways to pay. Elsewhere, only apps holding one of Apple’s link entitlements, limited to specific storefronts, may include them. Subscriptions (3.1.2) “must last at least seven days and be available across all of the user’s devices”, and before asking anyone to subscribe, you “should clearly describe what the user will get for the price.”

7. Too thin, too similar or copied (Guidelines 4.2, 4.3 and 4.1)

Apple’s footnote says the Design category “includes guidelines that prohibit copycat apps, apps with minimum functionality, and spam.”

  • Minimum functionality (4.2): your app needs “features, content, and UI that elevate it beyond a repackaged website”, and shouldn’t be primarily “web clippings, content aggregators, or a collection of links”.
  • Spam (4.3): don’t submit several Bundle IDs of the same app. In crowded categories, “dating, flashlight, sound effects, wallpaper, simple timers, and fortune telling,” Apple will “not accept new submissions unless they offer a meaningfully different or improved experience.”
  • Copycats (4.1): don’t copy a popular app, or use “another developer’s icon, brand, or product name in your app’s icon or name, without approval”.
  • Templates (4.2.6): apps made with a commercial template or app generation service “will be rejected unless they are submitted directly by the provider of the app’s content.”

In a crowded category, we’d use the review notes to make the case for “meaningfully different”.

8. Builds that never reach a reviewer

Some requirements stop a build before App Review sees it, because you can’t upload or submit until you meet them. As of September 2026, Apple’s Upcoming Requirements page lists these among the rules in force:

  • Since April 28, 2026, apps “must be built with Xcode 26 or later” using a 26 SDK.
  • Since September 9, 2026, iOS and iPadOS apps “must target iOS 13 or later.”
  • Since May 1, 2024, uploads need “approved reasons for the listed APIs used by your app’s code (including from third-party SDKs)”.
  • Since January 31, 2026, you need answers to the updated age rating questions “to avoid an interruption when submitting your app updates”.
  • Since October 16, 2024, app updates in the EU need your trader status under the Digital Services Act.

How to avoid App Store rejection: a check before you submit

Our short list, drawn from the rules above. The release checklist we use for nine apps covers the rest of a release.

  1. The release build runs on a real device with the latest OS.
  2. There’s no placeholder content, and every link works.
  3. The demo account works, won’t expire and has realistic data.
  4. The review notes cover non-obvious features, what changed and where each purchase lives.
  5. Every in-app purchase is in the submission and can be bought in the sandbox.
  6. Screenshots show the app in use, and the metadata makes no claim the app can’t back up.
  7. The privacy policy is linked in both places, purpose strings say why, and accounts can be deleted in the app.
  8. The servers stay up until the review is over.

What to do if your app is rejected

Read the message on your app’s App Review page in App Store Connect, then pick the response that fits:

  • Metadata only: edit it and reply to App Review’s message.
  • The reviewer missed something: reply in App Store Connect and explain, attaching a file if it helps. Apple says this “may help get your app on the store”.
  • A real problem: fix it and resubmit. If the submission held several items, you can also remove the rejected ones and go ahead with the rest.
  • A bug fix for an app already on the store: bug fixes “will not be delayed over guideline violations except for those related to legal or safety issues.” Reply to accept, and fix the other issue in your next submission.
  • You think App Review got it wrong: appeal to the App Review Board, with specific reasons your app complies. Apple allows one appeal per rejected submission and asks you to answer any requests for information first.

Apple also offers 30-minute App Review appointments over Webex to talk through the guidelines. What doesn’t help is resubmitting without a fix: if your app “is repeatedly rejected for the same guideline violation”, review “will take longer to complete.”

App Store rejection FAQ

How long does App Review take?

Apple says that on average, 90 percent of submissions are reviewed in less than 24 hours, though complex apps can take longer. For a critical bug fix or a launch tied to an event, you can request an expedited review.

Can App Store rejections get my developer account terminated?

The guidelines tie removal from the Apple Developer Program to dishonest or repeated behavior. Trying “to trick the review process, steal user data, copy another developer’s work, manipulate ratings or App Store discovery” gets your apps removed and you expelled, and Guideline 2.3.1(b) says “egregious or repeated behavior is grounds for removal from the Apple Developer Program.”

How we made this

We read Apple’s App Review Guidelines (last updated June 8, 2026), the App Review page, App Store Connect Help, StoreKit documentation and Upcoming Requirements in September 2026, and quoted them directly. Apple changes these pages often. The figures come from Apple’s App Store Transparency Reports for 2025 and 2024; the percentages and totals are our arithmetic, and the advice is ours. The ShipHappens line comes from the app’s source code; the photo is from Wikimedia Commons.

References

Image credits