Your first triage question isn't "which guideline?" — it's "does this need a new binary?" That single split decides whether you're back in review tonight or three days from now. Metadata rejections (2.3, most of 2.1's missing-info variants, privacy answers) get fixed inside App Store Connect and resubmitted without a build. Paywall, functionality, and SDK issues need Xcode, an archive, and another upload.
One caveat before the list: Apple renumbers and rewords the App Store Review Guidelines between revisions. The numbers below are the ones in current use as of writing, but always open the live guidelines and read the exact clause quoted in your Resolution Center message — that quoted text, not a blog's paraphrase, is what your reviewer is holding you to.
Which rejection reasons fire most often for subscription apps?
For paid-subscription iOS apps, the most common App Store rejection reasons cluster in four places: 2.1 App Completeness, 2.3 Accurate Metadata, 3.1.1 In-App Purchase and 3.1.2 Subscriptions, and 5.1.1 Data Collection and Storage. Subscription apps get hit disproportionately by 3.1.x because every paywall is a compliance surface.
Here's the triage table. Find your guideline, read the fix column, then check the "needs new build" column to know what tonight looks like.
| Guideline | Official section title | What the reviewer saw | Needs new build? | Typical turnaround |
|---|---|---|---|---|
| 2.1 | App Completeness | Crash on launch, dead demo account, backend down, missing sign-in credentials | Sometimes — no if it's just missing review notes | Hours to 1 day |
| 2.3 | Accurate Metadata | Screenshots showing features the build lacks, description promising unreleased functionality | No | Hours |
| 3.1.1 | In-App Purchase | A link or button that sends users to a web checkout for digital content | Yes | 1–3 days |
| 3.1.2 | Subscriptions | Paywall missing price, billing period, or links to Terms and Privacy Policy; no restore purchases | Yes | 1–3 days |
| 4.2 | Minimum Functionality | Thin wrapper around a website, or a single-screen utility | Yes, usually a real rebuild | Days to weeks |
| 4.3 | Spam | Near-duplicate of another app on your account or a template build | Yes | Days |
| 5.1.1 | Data Collection and Storage | Account required with no reason, no account deletion, permission prompt with no purpose string | Yes for most | 1–3 days |
| 5.1.2 | Data Use and Sharing | Tracking without ATT prompt, privacy nutrition labels contradicting SDK behavior | Sometimes | Hours to days |
Guideline 3.1.2 Subscriptions: the paywall disclosure checklist
Guideline 3.1.2 Subscriptions rejections almost always come down to something missing on the paywall screen itself, not the StoreKit code behind it. The reviewer opens your paywall, scans for required disclosures, and files a rejection when one is absent.
The rejection text usually reads like: "We were unable to find the following required information in your app's binary: a functional Restore Purchases button" or "the length of subscription, including price and period." Sometimes it's a screenshot of your paywall with a red circle around empty space.
Work the checklist in order before you resubmit:
- Subscription name and length of subscription — visible on the paywall, not buried in a modal.
- Price, and price per unit if you advertise one — "$59.99/year" is fine; "Unlock Pro" alone is not.
- A functional Restore Purchases button — tappable from the paywall, and it must actually restore.
- Links to your Terms of Use (EULA) and Privacy Policy — in the binary, tappable, loading real pages.
- The same Privacy Policy and EULA URLs in App Store Connect metadata, matching what's in the app.
- Trial terms stated plainly if you run one: what's free, for how long, what gets charged after.
The one that catches experienced devs is the third link check. Your Terms page loads fine on your machine because you're logged into a staging host; the reviewer taps it and hits a 404 or a Cloudflare challenge. Open both links in a private browser window on cellular before you resubmit.
Guideline 3.1.1 In-App Purchase: external links and the reader-app trap
Guideline 3.1.1 In-App Purchase fires when your app points users at any purchase path for digital content that isn't StoreKit. The mechanism is simple: Apple's reviewer follows every outbound link in your app, and if one lands on a checkout, pricing page, or "manage your plan" upgrade flow, you're rejected.
This is where the generic advice is wrong. You'll read "just remove the pricing page from your website" — that's overkill and it costs you web conversions. The rule the reviewer applies is about what your app surfaces, not what exists on the internet. What actually triggers the flag is an in-app button, link, or copy that steers a user off-platform to buy. A support link that happens to sit on a site with a pricing nav is a much weaker signal than a "Subscribe on the web and save" button.
Also note that entitlements exist — the US external-link entitlement, reader apps, and multiplatform-service carve-outs — and their terms have shifted repeatedly through court rulings and Apple policy revisions. Check the live guideline text for your case rather than trusting a year-old blog post.
The fix: audit every outbound URL, every "Manage subscription" destination, and your onboarding copy. Route account management to Apple's subscription management URL. Then rebuild and resubmit.
Guideline 2.1 App Completeness: the fastest rejection to fix
2.1 App Completeness is the most common rejection reason across all apps and often the cheapest to resolve, because it's frequently a review-notes problem, not a code problem. Reviewers see "unable to sign in," "app crashed on launch on iPad," or "we were unable to locate the features described."
The three failure modes and their fixes:
Dead demo account. Your test user expired, got rate-limited, or lives in a database you wiped. Create a permanent, never-expiring review account and put the credentials in App Store Connect review notes. Fix: minutes, no new build.
Crash on a device you don't own. Usually iPad, sometimes the oldest supported iOS version. Reviewers test on hardware you skipped. Pull the crash log from the rejection attachment, reproduce in the simulator, fix, rebuild. Fix: hours to a day, new build required.
Hidden features. Something is behind a feature flag, a server toggle, or a region gate the reviewer can't reach. Ship a review-mode path or explain the gate in review notes. Fix: varies.
If you're rejected under 2.1 with no crash attached, read the message twice — nine times out of ten it's asking for information, and a review-notes update plus a resubmit clears it the same day.
Guideline 4.2 Minimum Functionality and 4.3 Spam: structural, not cosmetic
4.2 Minimum Functionality and 4.3 Spam are the two rejections you can't fix in an afternoon, because they're judgments about the product, not the build. 4.2 says your app doesn't do enough native work to justify existing on the App Store; 4.3 says it looks too much like something else, often something else on your own developer account.
Micro-studio founders running several apps off a shared codebase hit 4.3 most. The pattern that trips it: same UI skeleton, same paywall, same screenshot template, different niche keywords. Apple's stance is that these should be one app with configuration, not five listings.
If you're rejected under 4.2, the fix is native capability the web can't provide — offline mode, widgets, notifications tied to real events, Shortcuts, on-device processing. If you're rejected under 4.3, consolidate or genuinely differentiate: separate onboarding, separate feature sets, separate visual identity. Budget days to weeks, not hours, and don't resubmit the same binary hoping for a different reviewer.
Guidelines 5.1.1 and 5.1.2: data collection and privacy manifests
5.1.1 Data Collection and Storage and 5.1.2 Data Use and Sharing rejections usually trace to three things: forcing account creation for features that don't need it, offering no in-app account deletion, or shipping permission prompts without a clear purpose string.
The subtler one is SDK-level: your privacy manifest, or a third-party SDK's manifest, declaring data types that contradict your App Store Connect nutrition labels. Analytics and attribution SDKs are the usual culprits, and the mismatch surfaces at review, not at build time.
Run your bundle through a privacy manifest checker before you submit rather than after you're rejected. Then confirm your nutrition labels match what the manifests actually declare, add an account deletion path that works without emailing support, and make every NSUsageDescription string say what you do with the data.
Where compliance meets your conversion numbers
Rejections and revenue collide at the paywall. The disclosures 3.1.2 requires — price, period, trial terms, restore, Terms and Privacy links — are the same elements that shape whether a user trusts the screen enough to start a trial, so fixing compliance and testing conversion are the same job.
Trial length is a good example. Per RevenueCat's State of Subscription Apps 2026, median trial-to-paid conversion is 42.5% for trials of 17–32 days vs 25.5% for trials under 4 days, yet the share of apps using trials of under 4 days rose from 42.1% (2025 report) to 46.5% (2026 report). Those are medians across 115,000+ apps and $16B+ tracked revenue, primarily 2025 data — a distribution, not a promise. If you change trial length to chase that, your paywall copy has to change with it, and the new copy has to carry every 3.1.2 disclosure. Ship both edits in the same build.
AppApex tracks App Store Review Guideline changes and flags at-risk setups like non-compliant paywalls, so the audit happens before submission instead of in Resolution Center. Its Conversion agent works the same paywall for funnel leaks, and on the Growth and Studio tiers Autopilot can ship approved changes through Superwall, RevenueCat, and App Store Connect — with per-agent budgets, quiet hours, kill switches, a full audit log, and a 7–14 day watch window that auto-rolls-back if lift falls short.
Want a read on your current setup before your next submission? Run your App Store ID through the free Growth Audit — health score and analysis, no account required.
Last updated September 4, 2026