App Store Rejection: The 5 Categories Apple Cares About and How to Survive Them

If your app just got rejected from the App Store, your first instinct is probably to fire off a reply or resubmit with a tweak. Don't. App Store rejections fall into one of five Apple-defined categories, and the right move depends on which category yours is in. Resubmitting blind is how teams get rejected six times in a row.

This is the field guide. It is based on the rescue work we did to take a React Native healthcare app through dual-store approval in 4 weeks after the previous team had been failing review for months. The patterns repeat across every iOS rescue we run.

The five categories

Apple's App Store Review Guidelines organize every rejection into one of five top-level categories:

1. Safety (guideline 1.x) — content, user safety, child safety, physical harm, app violence policies
2. Performance (guideline 2.x) — app completeness, accuracy, crashes, beta testing rules, hardware compatibility
3. Business (guideline 3.x) — payments, monetization model, subscriptions, free tier rules, third-party services
4. Design (guideline 4.x) — copycats, minimum functionality, integrated services, gambling, scraping
5. Legal (guideline 5.x) — privacy, intellectual property, gaming, contests, health, government

The first thing to do when you get rejected: read the rejection message carefully and identify which top-level category Apple is citing. The reviewer will reference a specific guideline number. That number tells you almost everything about what to do next.

Category 1: Safety

Rejection patterns we see most often:

• 1.1 Objectionable content — user-generated content surfaces without moderation, or with insufficient moderation tools
• 1.2 User safety — apps that handle health, dating, ride-sharing, or other safety-sensitive interactions without clear safety mechanisms
• 1.3 Kids Category — apps in the Kids Category that contain ads, in-app purchases, or non-COPPA-compliant tracking

How to resolve: Most Safety rejections need an actual product change, not just a metadata fix. Apple wants to see moderation, reporting, blocking, and review surfaces. We have walked rejections through resolution by adding user-reporting flows, content-moderation queues, and an admin tool the client did not have before.

The rejection reply matters here. Acknowledge Apple's concern, explain the implementation, and link directly to the part of the app where the safety mechanism lives.

Category 2: Performance

This is the most common rejection category. Patterns:

• 2.1 App Completeness — app crashes on launch, broken features, placeholder content, demo accounts that don't work
• 2.2 Beta Testing — using App Store distribution for what should be TestFlight (rare, but real)
• 2.3 Accurate Metadata — screenshots that don't match the actual app, marketing copy that promises features the app doesn't deliver
• 2.5 Software Requirements — apps that don't function properly on current iOS, use private APIs, or have hardware incompatibilities

The 2.1 sub-rejection (App Completeness) is the one we see most often. Crashes on first launch in the reviewer's environment, even when they don't reproduce on the developer's local devices, are an instant rejection.

How to resolve: Test on the same iOS version Apple's review team is on, on the device categories they test. Verify demo accounts work. Strip out any placeholder text or content that looks unfinished. Verify your binary actually launches cleanly on a freshly-restored iOS device.

If the reviewer mentions a crash but doesn't provide a stack trace, request it through Resolution Center. Apple's reviewer can attach a crash log if you ask.

Category 3: Business

This is where most healthcare and subscription apps get caught. Patterns:

• 3.1.1 In-App Purchase requirement — digital subscriptions, digital content, or digital services must use Apple's IAP, with Apple's 15-30% commission
• 3.1.3 "Reader" Apps — exceptions for apps that primarily deliver content the user purchases elsewhere (Netflix, Spotify, Kindle), with strict rules about how external purchase paths can be referenced
• 3.1.5 Goods and Services Outside of the App — physical goods, professional services, and certain real-world experiences can route outside of IAP

If your app has any subscription or digital purchase, assume the reviewer will look for IAP compliance. Even hinting that users can subscribe at your website is enough to get rejected under current interpretations of 3.1.1.

How to resolve: Implement IAP for any digital subscription or content purchase. For "reader" apps, follow the exact wording rules Apple publishes. For services and physical goods, document clearly in the reviewer dialog that the goods are physical or the service is delivered outside the app.

This category often surfaces as a binary choice: implement IAP, or remove the purchase path entirely from the iOS app.

Category 4: Design

Patterns:

• 4.0 Design — minimum functionality (apps that are too thin to justify being native apps; web apps shipped as iOS apps are common offenders)
• 4.3 Spam — copycat apps, white-labeled clones, multiple identical apps from one publisher
• 4.5.4 Push Notifications — push notifications used for marketing without user consent

The 4.0 minimum-functionality rejection is the trickiest. Apple wants iOS apps to do something native that justifies App Store distribution. A thin wrapper around a website often gets rejected here, especially for first submissions.

How to resolve: For 4.0, add functionality that requires native APIs (offline mode, push notifications, native sharing, device-specific features). For 4.3, ensure your app is distinct from other apps in your portfolio. For 4.5.4, get explicit user opt-in for marketing push notifications.

Category 5: Legal

Patterns:

• 5.1 Privacy — privacy manifest (PrivacyInfo.xcprivacy), data collection disclosure, third-party SDK declarations
• 5.1.3 Health and Health Research — apps that handle health data have additional disclosure and consent requirements
• 5.2 Intellectual Property — using trademarks, copyrighted content, or branded materials without permission
• 5.3 Gaming, Gambling, and Lotteries — strict regional rules
• 5.6 Developer Code of Conduct — rare but possible

The 5.1 privacy category is the one we see expanding fastest. Apple introduced privacy manifests in 2024 and tightens the requirements every release. Third-party SDKs (analytics, ads, payments, crash reporting) all need to be declared, and their tracking domains itemized.

5.1.3 (Health and Health Research) is where healthcare apps get caught. If your app handles any health data, expect deeper scrutiny on consent flows, data-handling disclosures, and third-party analytics. We have 5 years of HIPAA experience in this category and the pattern is consistent: assume Apple will ask for more privacy disclosure than the law requires, and prepare your privacy policy and in-app consent flows accordingly.

How to resolve: Ship a complete PrivacyInfo.xcprivacy file declaring every data type collected, every SDK that touches user data, and the tracking domains each SDK contacts. For 5.1.3, add explicit consent screens for health data, clear data-handling explanations, and an in-app privacy summary.

The 4-week approval pattern

The rescue we ran that cleared dual-store approval in 4 weeks went through every one of these categories during the engagement. The pattern that worked:

1. Diagnose the actual category before doing anything. The previous team had been treating a 5.1 rejection as a 2.1 issue. Different fix, wrong fix, repeat rejection.
2. Pre-resolve before resubmission. Privacy manifests, IAP routing, SDK declarations, content moderation surfaces. Everything Apple might ask about gets answered before the submission goes in.
3. Write the reviewer dialog like it matters. It does. The reviewer reads the reply note in App Store Connect before they retest. A reviewer dialog that walks Apple through the changes, references the specific guideline they cited, and points at the exact code or surface that resolves the concern shortens the review cycle dramatically.
4. Submit once you are confident, not when you are tired. Resubmission cycles burn time. A submission that resolves all five potential categories on the first try beats four submissions that each resolve one.

What teams almost always get wrong

• Treating the rejection as one problem when it is several. Apple often cites one guideline in the rejection message and finds two more on resubmission. Address all five categories preemptively.
• Misdiagnosing the category. A 5.1 privacy issue masquerading as a 2.1 crash issue is the most common case we see. The actual fix is different.
• Skipping the reviewer dialog. Apple's reviewers are humans. A reviewer who can see exactly what changed and why is faster to approve than one who has to re-read the binary and guess.
• Resubmitting without pre-testing on the reviewer's environment. Apple tests on iOS versions and device combinations the dev team often does not. A clean local build is not enough.
• Underestimating Play Store policy. Google Play has its own enforcement and rejects on different grounds (data safety form, sensitive permissions, restricted content). Dual-store rescue is more than two parallel iOS rescues.

If you are stuck in a rejection cycle

If you have been rejected three or more times on the same submission, the pattern almost always is: the rejection cause was misdiagnosed, the fix targeted the wrong code path, or the reviewer dialog made things worse. The audit re-diagnoses the actual cause; the rescue targets the right fix.

Our rescue starting point is published: a $2,500 Quick Scan or$5,000 Full Audit gives you a written report with the specific dollar number for the rescue before any work begins. Rescue engagements start at $8,000 after the required audit.