Why apps get rejected: 285 public App Review cases analysed

First published on tychelabs.net.

We read 419 public posts about App Store rejections and classified the 285 real cases by guideline and outcome. Here is what gets apps rejected, what fixed it, and the dataset.

We read 419 public posts in which developers asked for help with App Store review, and classified the 285 that describe a real rejection of their own app. The answer to "why do apps get rejected?", in the cases developers post about:

• Payments and in-app purchase: 18% (50 cases). Digital content sold outside in-app purchase, and subscription screens missing the price, terms or a restore option.
• Spam and copycats: 13% (38). Guideline 4.3: an app too similar to others, or to the developer's own apps.
• Missing information or demo access: 13% (36). The reviewer could not log in, could not find a feature, or asked for a video.
• Privacy: 8% (24). Purpose strings, sign-up walls, tracking without the prompt, privacy answers that don't match the app.
• Crashes and bugs: 8% (23). Often a reviewer device with no network, an iPad, or a purchase flow with no products loaded.
• Metadata and screenshots: 7% (21), automated upload checks: 6% (16), and everything else under 4% each.

By guideline number, 2.1 (App Completeness) is cited in 24% of cases, 4.3 (Spam) in 12% and 5.1.1 (Data Collection) in 8% [7]. In 63% of cases the developer quoted the guideline from Apple's message; the rest we inferred from what they described.

Outcomes are less clear than causes. In the Reddit, Stack Overflow and Hacker News threads, 72 developers came back to say what happened: 39 (54%) were approved, almost all after changing the app or listing, and 33 were still rejected at their last update. Sixteen developers in the whole dataset filed a formal appeal; one says the appeal itself got the app approved.

Where the data comes from

Source	Cases	What we read
Reddit (r/iOSProgramming, r/iosdev, r/reactnative, r/swift and five more)	112	A random sample of 140 posts with "reject", "appeal" or "guideline" in the title, 2023 to October 2026, with the poster's later comments and the top replies
Apple Developer Forums, App Review tag	106	The first post of the 156 threads on the tag's 20 most recent listing pages that mention a rejection or guideline [8]
Stack Overflow	48	Questions about App Store rejections from 2019 on, with their answers
Hacker News	19	"My app was rejected" stories from 2019 on, with comments
Total	285	134 more posts were read and left out: questions asked before submitting, waits with no rejection, Google Play, news about other companies' apps, duplicates, and cases from before 2019

Every case in the dataset links to its public source. We removed usernames, post titles and app names.

The most common reasons, ranked

Theme	Cases	Share	Main guidelines cited
Payments and in-app purchase	50	18%	3.1.1, 3.1.2, 2.1(b)
Spam or copycat	38	13%	4.3(a), 4.3(b), 4.1
Missing information or demo access	36	13%	2.1
Other or unclear	25	9%	various
Privacy: policy, permissions, data use	24	8%	5.1.1, 5.1.2
Crash or bug	23	8%	2.1
Metadata and screenshots	21	7%	2.3.x
Automated upload checks	16	6%	ITMS-91061, ITMS-91064 and others
Design and platform conventions	11	4%	2.5.x, 4.0
Intellectual property and trademarks	10	4%	5.2.x
Regulated or sensitive category	10	4%	1.4.1, 5.1.1(ix)
Minimum functionality or web wrapper	8	3%	4.2, 4.2.2
Login and Sign in with Apple	6	2%	4.8
User-generated content	4	1%	1.2
Account deletion	3	1%	5.1.1(v)

What developers post about is not what Apple rejects most

Apple publishes how many submissions it rejects under each section of the guidelines. In 2025 it reviewed 9,100,620 submissions and rejected 2,093,244 [1]. Comparing the five named sections with the cases in our dataset that cite a guideline:

Section	Share of Apple's 2025 rejections [1]	Share of public cases
Performance (2.x)	50%	41%
Legal (5.x)	18%	18%
Design (4.x)	15%	23%
Business (3.x)	11%	15%
Safety (1.x)	6%	3%

Design and Business are over-represented in public posts; Performance is under-represented. That fits what the posts say. A crash or a broken link is fixed quietly and resubmitted. A 4.3 spam rejection or a payments dispute has no obvious fix, so developers go looking for help. If you are reading this after a 4.3 or a 3.1.1 rejection, you are in the group most likely to need a second opinion, and most likely to find conflicting advice.

Got a rejection message in front of you? Paste it into our free App Store rejection decoder. It matches the guideline, shows Apple's wording and gives the usual fix, in your browser, with nothing sent to us.

What fixed it, by reason

These are fixes the developers themselves confirmed worked (50 cases), plus the advice repeated most often in replies where the outcome was not reported.

Payments and in-app purchase (50 cases)

Apple's rule is direct: if you unlock features or content in the app, "you must use in-app purchase", and apps "may not use their own mechanisms to unlock content or functionality" [3]. For subscriptions, Apple expects you to "clearly describe what the user will get for the price" before asking anyone to subscribe [3].

Confirmed fixes in the dataset:

• Adding Terms of Use (EULA) and privacy policy links on the paywall itself, not only in the listing.
• Stating the trial length and the billed price next to the subscribe button, and fixing a paywall layout that broke on iPad.
• Attaching the in-app purchases to the first submission, and handling the case where the store returns no products instead of showing a blank screen.
• Signing the Paid Apps agreement and adding banking details, so StoreKit returns the products at all.

The repeated advice for 3.1.1: sell digital subscriptions through in-app purchase even if you also sell on the web, remove links and references to web pricing inside the app, and keep Stripe for physical goods and services.

Spam and copycats (38 cases)

Guideline 4.3 has two parts. 4.3(a) says "Don't create multiple Bundle IDs of the same app"; 4.3(b) says "Don't submit apps that are indistinguishable from what's already widely available" and names dating, flashlight, wallpaper and simple timer apps among the saturated categories [3]. This was the theme with the most unresolved cases: 16 of the 22 with a reported outcome were still rejected.

Confirmed fixes: a redesigned generic icon with review notes explaining the difference; a distinctive core interface; rewritten description, keywords and screenshots plus a reply explaining the mechanic no other app has; removing third-party service names from the app name and subtitle. The pattern is that the difference has to be visible in the first screen and the screenshots, not only described in a reply. Our guide to 4.3 rejections covers when to reply, appeal or rebuild.

Missing information or demo access (36 cases)

Apple asks for "either an active demo account or fully-featured demo mode" for any account-based features [3]. The typical case is a one-time code login the reviewer cannot complete, a demo account that expired, or a hardware feature with no video. Confirmed fixes were simple: update the test account and reply in the review thread; resubmit unchanged after the reviewer mistyped the demo email. Advice repeated in replies: a demo account with a fixed one-time code, a screen recording from a real device, and step-by-step review notes for anything not on the first screen.

Privacy (24 cases)

The privacy cases split into four kinds: vague purpose strings ("we need your location"), apps that require an account before showing anything, tracking or ads loaded before the App Tracking Transparency prompt, and App Privacy answers that do not match what the SDKs collect [6]. Six of the eight with a reported outcome were approved. Confirmed fixes: making login optional and moving it to settings; showing content before asking for sign-up; showing the tracking prompt before the consent form and adding SKAdNetwork identifiers; correcting the App Privacy answers; and changing a pre-permission button from "Enable microphone" to "Continue", which is what Apple's privacy guidance asks for on a screen shown before the system prompt [4].

Crashes and bugs (23 cases)

Many reported crashes were not reproducible by the developer. The common causes in replies: the reviewer's device had no network or used IPv6, the app was tested on an iPad, or the purchase screen loaded before products arrived. Confirmed fixes: replacing a location package that crashed, handling a missing network connection before fetching products, and in one case replying with evidence that the reviewer's device was offline, after which the same build was approved. The advice: test the release build on a real device with no network, on an iPad and on IPv6, and read the crash log Apple attaches.

Metadata and screenshots (21 cases)

Apple product names in the subtitle, trademarks in keywords, "beta" in the description, screenshots that show the wrong device or a broken layout, and paid features not labelled as paid. Confirmed fixes were all edits to the listing, and several replies point out that a metadata-only rejection can often be fixed without a new build.

Automated upload checks (16 cases)

Emails such as ITMS-91061 (missing privacy manifest) arrive before human review. Apple requires privacy-impacting third-party SDKs to include a privacy manifest [5]. Confirmed fixes: bundling the SDK's privacy manifest with the correct resource path, removing an empty tracking-domains array, and replacing a plugin that referenced non-public symbols. Most were solved by updating the SDK.

Appeals and repeat rejections

Sixteen developers filed a formal appeal to the App Review Board. One reported approval because of the appeal, one was approved after changing the app anyway, ten were still rejected at their last update and four did not say. Apple describes the appeal as the route when "you feel we misunderstood your app" [2]. In this data it rarely worked on its own; a change the reviewer can see worked more often.

Where developers said how many times they had been rejected for the same submission (53 cases), the median was 2, and 24 (45%) had been rejected three times or more, up to 16. The long runs share a pattern: each resubmission fixed only the sentence in the last message, and the next reviewer found the next issue. Apple's App Review appointments (30-minute video calls) were suggested in several threads as the way out of that loop [2].

Method

• Collection (27 October 2026): Reddit posts from nine iOS and cross-platform subreddits (2023 to 27 October 2026) via the Arctic Shift archive of public Reddit data [9], sampled at random from 801 posts with "reject", "appeal" or "guideline" in the title and at least two comments; the 20 most recent listing pages of the App Review tag on Apple Developer Forums (first posts only, so outcomes there are mostly unknown); Stack Overflow and Hacker News posts found by search, with answers and comments.
• Classification: each post was read and coded against a written codebook: valid or not, guideline (quoted or inferred), one of 15 themes, outcome (only from the poster's own words), the fix and whether the poster confirmed it, number of rejections, framework, and whether a formal appeal was filed.
• Exclusions: 114 of 419 posts (hypothetical questions, waits with no rejection, Google Play, news, duplicates) and 20 Stack Overflow and Hacker News cases from before 2019, when the guidelines used different numbering.
• Dataset: 285 rows, one per case, with the source link. Free to reuse under CC BY 4.0 [7].

Caveats

• This is what developers post about, not a random sample of rejections. Hard, confusing and unresolved cases are over-represented; quick fixes rarely get a post.
• Outcomes are often missing. 173 of the 285 cases have no reported outcome, and the Apple forum cases are first posts only.
• Inferred guidelines. In 37% of cases the guideline was inferred from the description, or left as unknown.
• One reader per post. Each post was coded once, against a fixed codebook, and the coding was spot-checked; a second coder might file a few borderline cases under a neighbouring theme.
• Rules change. The guidelines are updated several times a year. Check the current wording [3] before acting on an old fix.

A checklist built from the 285 cases

• Every paywall shows the price, the period, the trial terms, Restore purchases, and links to the Terms of Use and privacy policy.
• In-app purchases are attached to the submission and the app copes when no products load.
• The demo account works without a one-time code, and the review notes say where every feature is.
• A screen recording from a real device is attached for anything that needs hardware, a location or an account state.
• The release build has been run with no network, on an iPad and on IPv6.
• The app does something visible in its first screen and screenshots that similar apps do not.
• The app name, subtitle and keywords contain no other company's trademarks and no "beta".
• Purpose strings say why the app needs access, with an example; sign-up is not required to see what the app does.
• App Privacy answers match what every SDK in the build collects, and each SDK ships a privacy manifest.

Questions we get asked

What is the most common reason apps get rejected?

Across all App Store submissions, Apple's 2025 transparency report shows Performance (section 2, which includes 2.1 App Completeness) accounts for about half of rejections in the five named sections. In the 285 public cases developers posted about, payments and in-app purchase was the largest theme (18%), followed by spam and copycats (13%) and missing information or demo access (13%). Guideline 2.1 was the single most cited number, in 24% of cases.

Does appealing an App Store rejection work?

Sometimes, but rarely on its own in our data. Of 16 developers who filed a formal appeal to the App Review Board, one reported that the appeal got the app approved and one was approved after changing the app; ten were still rejected at their last update. Apple says an appeal is for when you believe it misunderstood your app. If the rejection is about something you can change, a visible change usually works faster.

How many times do apps get rejected before approval?

Where developers said how many rejections they had for the same submission, the median was 2, and 45% had three or more. Apple's own report shows 387,087 submissions were approved in 2025 after an earlier rejection.

Do I need a new build to fix a rejection?

Not always. Rejections about metadata, screenshots or missing information can often be fixed by editing the listing or replying in App Store Connect. Changes to the app itself, such as a paywall, a purpose string or a crash, need a new build.

Can I use the dataset?

Yes. The CSV is free to download and reuse under CC BY 4.0: credit Tyche Labs and link to this page. It has one row per case with the guideline, theme, outcome, fix summary and a link to the public source, and no usernames, titles or app names.

What to do next

1. Free: paste your rejection message into our App Store rejection decoder for the guideline, Apple's wording and the usual fix.
2. Talk it through: book a 20-minute call and we will tell you honestly whether to reply, change the app or appeal.
3. Fixed price: our App Store launch and rejection rescue starts at £650: we review the build, the listing and the rejection, and in two working days you have a fix plan, or we make the fixes for you.

Sources

1. Apple, "2025 App Store Transparency Report" (seen 27 Oct 2026): https://www.apple.com/legal/app-store/transparency/2025/
2. Apple Developer, "App Review": appeals and appointments (seen 27 Oct 2026): https://developer.apple.com/distribute/app-review/
3. Apple Developer, "App Review Guidelines" (2.1, 3.1.1, 3.1.2, 4.3) (seen 27 Oct 2026): https://developer.apple.com/app-store/review/guidelines/
4. Apple Developer, "Human Interface Guidelines: Privacy" (seen 27 Oct 2026): https://developer.apple.com/design/human-interface-guidelines/privacy
5. Apple Developer, "Third-party SDK requirements" (seen 27 Oct 2026): https://developer.apple.com/support/third-party-SDK-requirements/
6. Apple Developer, "App privacy details on the App Store" (seen 27 Oct 2026): https://developer.apple.com/app-store/app-privacy-details/
7. Tyche Labs, "Public App Store rejection cases, classified" (dataset, CSV, 285 rows, collected 27 Oct 2026): https://www.tychelabs.net/data/app-store-rejection-cases.csv
8. Apple Developer Forums, "App Review" tag (listing pages 1 to 20, read 27 Oct 2026): https://developer.apple.com/forums/tags/app-review
9. Arctic Shift, archive and API of public Reddit posts and comments (queried 27 Oct 2026): https://arctic-shift.photon-reddit.com/