Why Apps Get Rejected from the App Store (2026 Data + Fixes)

Apple rejected about 2.09 million of the 9.1 million submissions it reviewed in 2025 — roughly 23%. Performance problems caused more rejections than every other category combined, and Apple says over 40% of unresolved issues come down to one guideline: App Completeness. Crucially, that 23% counts submissions rather than apps, and more than 387,000 submissions were approved after an earlier rejection. A rejection is normally a round trip, not a verdict. Here is what actually gets rejected, in Apple's own order of volume, and how to fix each one.

Verified against Apple's App Store transparency reporting and App Review documentation, July 2026.

The real numbers, from Apple

Most articles on this topic rank rejection reasons by impression. Apple publishes the actual counts in its App Store transparency reports, broken down by which section of the review guidelines the submission failed. In 2025, out of 9,100,620 submissions reviewed and 2,093,244 rejected:

Guideline section	Rejections (2025)	What it covers
Performance	1,354,418	Crashes, bugs, incomplete builds, broken links, placeholder content, hardware compatibility
Legal	495,673	Privacy, data handling, intellectual property, regulated categories
Design	415,532	Minimum functionality, webview wrappers, spam, copycats
Business	283,820	Payments, subscriptions, monetisation rules
Safety	151,159	Objectionable or harmful content, user-generated content moderation
Other	4,145	—

Those figures sum to more than the total because one submission can cite several guidelines. The distribution is the useful part: Performance alone accounts for more rejections than Legal, Design, Business and Safety put together. The most common reason an app is rejected is not a policy disagreement — it is that the app did not work properly when a reviewer opened it.

Two more numbers worth holding onto. The rate fell year on year: 24.85% of submissions in 2024, 23.00% in 2025 — so review is not getting harsher. And 387,087 submissions were approved in 2025 after being rejected earlier, which is the clearest evidence that a rejection is a step in the process rather than the end of it.

1. The app is not finished (Guideline 2.1, App Completeness)

Apple states plainly that over 40% of unresolved review issues relate to App Completeness. This is the single biggest cause of delay and rejection, and it is entirely self-inflicted: placeholder text, empty screens, "coming soon" sections, broken support or privacy-policy URLs, or a build that was not the final one.

Fix: submit a finished app. Click every link in your metadata — support URL, marketing URL, privacy policy URL — and remove every piece of lorem ipsum before you submit, not after Apple points at it.

2. Crashes and bugs

The largest slice of the Performance category. A reviewer opens your app on a real device, and if it crashes or a core feature does not work, that is the review over.

Fix: test on a real device rather than only the simulator, on the oldest OS version you claim to support. Most crash rejections are the app meeting real hardware for the first time.

3. A missing demo account

If any part of your app sits behind a login and you did not provide working credentials, the reviewer physically cannot assess it. Apple asks for either a live demo account or a fully featured demo mode.

Fix: put working credentials in App Review Information, and if the account uses two-factor authentication, supply the codes in the Notes field in advance. Otherwise review stalls while Apple tries to reach you.

4. Privacy declarations that do not match the app

The bulk of the Legal category. Your App Privacy details must describe what the app actually collects — including data collected by every third-party SDK you have embedded, not just your own code. A privacy policy that fails to say what is collected, who it is shared with, or how it is retained and deleted is a rejection.

Fix: audit your SDKs before you fill the form. Analytics, crash reporting, advertising and attribution libraries all collect something, and it is your disclosure to make. Since May 2024, uploads must also declare approved reasons for certain APIs, including where a third-party SDK is what uses them.

5. It is a website in an app (Guideline 4.2, Minimum Functionality)

The headline item in the Design category, and the one that decides whether an app can exist at all. Apple expects "features, content, and UI that elevate it beyond a repackaged website", and says that an app which is not "particularly useful, unique, or 'app-like,'" does not belong on the App Store. Guideline 4.2.2 adds that apps should not primarily be "marketing materials, advertisements, web clippings, content aggregators".

Fix: there is no metadata trick for this one — it is a decision made when you chose how to build. A wrapped website fails on its nature, not its presentation. Building a genuinely native app avoids the category entirely.

6. Generated or template apps submitted by the wrong party (Guideline 4.2.6)

Rarely mentioned anywhere, and specifically relevant if you built your app with a no-code tool. Apple rejects apps created from a commercialised template or app-generation service unless they are submitted directly by the provider of the app's own content.

Fix: submit under your own Apple Developer Program account. Read plainly, the rule says the business whose app it is must be the one submitting it — which is why any builder that submits every customer's app from its own account is the exact pattern 4.2.6 exists to stop.

These two are the only reasons on this list you cannot fix after the fact. Every other item is a build, a form or a link you can correct and resubmit. Whether your app is a wrapped website, and whose account submits it, are decided when you pick a tool. Choicely builds real native iOS and Android apps — not webview wrappers — and you publish under your own developer account, which is what 4.2.6 requires. Start free →

7. Misleading or inaccurate metadata

Screenshots that show features the app does not have, descriptions promising more than it does, or a name and icon that imply an association you do not have.

Fix: screenshots must show the app as it exists today. If you redesigned since your last release, retake them.

8. Spam and near-duplicates (Guideline 4.3)

Apple tells developers not to "create multiple Bundle IDs of the same app" and not to submit apps "indistinguishable from what's already widely available". Several categories now need a meaningfully different experience to be accepted at all.

Fix: one app, one Bundle ID. If you serve several clients, Apple's guidance points to a single app with an in-app picker rather than a family of near-identical submissions. Note that Apple revised 4.3 on 8 June 2026, so re-read it if you are close to this line.

9. Undisclosed sharing with third-party AI

Newer and easy to miss. Since November 2025, guideline 5.1.2(i) requires that you "clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so."

Fix: if your app sends user content to an external AI service, say so and ask first. Adding an AI feature to an existing app makes this a new requirement for you.

10. Payments and subscription rules

The Business category. Selling digital content outside the store's payment system, subscriptions that do not disclose their terms clearly, or pricing that does not match what the listing implies.

Fix: if you sell digital goods used inside the app, use In-App Purchase. Note that since 15 July 2026 in-app purchases and subscriptions are submitted through the same "Add for Review" flow as your app version, not a separate one.

11. Objectionable or unmoderated user content

The Safety category. Apps with user-generated content need moderation, reporting and blocking — the absence of those is itself the rejection.

Fix: ship a report mechanism, a block mechanism and a stated moderation process before submitting, not after your first incident.

12. Regional and regulatory declarations

Increasingly common and entirely avoidable. Export compliance, content rights for third-party media, age ratings, and — for EU distribution — verified trader status under the Digital Services Act, without which apps are removed from the EU App Store.

Fix: work through the declarations in App Store Connect rather than clicking past them. Each one is a question with a right answer for your app, and guessing produces a rejection weeks later.

What gets you rejected on Google Play

Google publishes no rejection rate, so treat any percentage you see for Play as unsourced. What it does publish is enforcement scale: in 2025 Google says it prevented over 1.75 million policy-violating apps from being published, banned more than 80,000 developer accounts, stopped over 255,000 apps from getting excessive access to sensitive user data, and runs over 10,000 safety checks on every app it publishes.

The recurring causes are different from Apple's:

Area	What goes wrong
Data safety	The declaration misses what third-party SDKs collect, or contradicts the privacy policy. The most common area by a distance
Spam & minimum functionality	Play's counterpart to Apple's 4.2 — webview wrappers, text-only or single-purpose apps, and apps that fail to install, load or respond
Restricted permissions	Requesting broad permissions without a qualifying use case. Notably, accessibility services may not be used to let an app autonomously plan and execute actions — relevant to anything agentic
Misleading metadata	Promotional or ranking claims in graphic assets, keyword stuffing, descriptions that oversell

One structural reassurance: on Play, a rejection is not a strike. Enforcement escalates from rejection, which carries no standing penalty, through removal, then suspension, then account termination. Fixing and resubmitting is the normal path.

You have been rejected — now what

Apple tells you which guideline you failed. That is the whole diagnosis, and it is more specific than it first looks: guideline numbers map to the categories above, so 2.1 means "not finished", 4.2 means "not enough of an app", 5.1.x means "privacy".

Fix the cited issue, then resubmit. If the problem was metadata, a declaration or a demo account, you often do not need a new build at all — which is why many rejections are resolved the same day. Reply in Resolution Center if you genuinely disagree, and include specifics rather than a restatement.

And keep the base rate in mind: 387,087 submissions were approved in 2025 after an earlier rejection. Being rejected once puts you in very ordinary company.

Most of this list is checkable before you submit. Crashes, placeholder content, broken links, privacy declarations that don't match the app, metadata that oversells — Choicely's Publish Assistant checks your app against Apple's and Google's rules before submission rather than after. And because Choicely builds real native apps rather than webview wrappers, reasons 5 and 6 above are not risks you have to design around. Start free →

Pre-submission checklist

No placeholder text, empty screens or "coming soon" anywhere
Support URL, marketing URL and privacy policy URL all load
Tested on a real device, on the oldest OS version you support
Demo account credentials — and any 2FA codes — in App Review Information
App Privacy details cover every third-party SDK, not just your own code
Screenshots show the app as it exists today
One app, one Bundle ID
Third-party AI data sharing disclosed and consented, if applicable
Moderation, reporting and blocking shipped if you allow user content
Export compliance, content rights and age rating answered deliberately
EU trader status provided if you distribute in the EU
Submitted under your own developer account (Guideline 4.2.6)

What percentage of apps get rejected from the App Store?

Apple rejected 23.00% of submissions in 2025 — 2,093,244 out of 9,100,620 — and 24.85% in 2024. Read that carefully: it counts submissions, not apps, and Apple notes one app may be submitted several times before approval. It is not the share of apps that fail, and it is not a first-submission rate. Claims that 40–60% of first submissions are rejected have no traceable source.

What is the most common reason for App Store rejection?

Incompleteness. Apple says over 40% of unresolved review issues relate to Guideline 2.1, App Completeness — placeholder content, broken links, missing information, or a build that was not final. By category, Performance caused 1,354,418 rejections in 2025, more than Legal, Design, Business and Safety combined.

Does a rejection hurt my chances next time?

No. In 2025, 387,087 submissions were approved after an earlier rejection. On Google Play, enforcement explicitly escalates from rejection — which carries no standing penalty — through removal and suspension, so a plain rejection is not a strike against your account.

Will my app be rejected for being built with a no-code tool?

Not for that reason alone, but two guidelines matter. Guideline 4.2 rejects apps that are essentially a wrapped website, so a tool producing webview wrappers is a real risk. And Guideline 4.2.6 rejects template or generated apps unless submitted by the provider of the app's own content — meaning you should submit under your own developer account, not the builder's.

How do I fix a rejection?

Apple cites the specific guideline. Fix that issue and resubmit — often without a new build if the problem was metadata, a declaration or a missing demo account. If you disagree, reply in Resolution Center with specifics. On Google Play, a rejected production-access application means starting a fresh 14-day closed test, so it pays more there to get it right first time.

Why do Google Play submissions get rejected?

Most often the data safety declaration misses what third-party SDKs collect, or contradicts the privacy policy. After that: minimum functionality, restricted permissions requested without a qualifying use case, and misleading store listing metadata. Google publishes no rejection rate, so treat any percentage you see for Play as unsourced.

Rejections cost time, not money — but they cost time you did not plan for. Choicely builds real native iOS and Android apps free, 300 credits every month and no credit card, and the Publish Assistant checks your app against the rules above before you submit.

Sources & disclosure: rejection counts and the per-guideline breakdown come from Apple's App Store transparency reporting for 2024 and 2025; the common-cause list and the App Completeness figure come from Apple's own App Review documentation; guideline wording is quoted from the App Store Review Guidelines; Google Play enforcement figures come from Google's 2025 safety report. All verified July 29, 2026. Where this article says a figure does not exist — a Google Play rejection rate, a first-submission rejection rate — that reflects the absence of any published source, not an oversight. Choicely publishes this page and sells an app-publishing product, so we have a commercial interest in it. Guidelines change; we re-verify quarterly.