App Store review: rejection patterns that waste release cycles and how to prevent them

App Review problems are rarely surprising in hindsight.

Most rejected iOS releases fail on practical details: the reviewer cannot access the app, the metadata promises something the binary does not do, an entitlement flow is broken, privacy answers drifted, or a paid feature routes users through the wrong purchase path.

The painful part is not only the rejection. It is the interruption. A release that should be a controlled shipment turns into context switching across App Store Connect, Xcode archives, legal copy, test accounts, backend flags, screenshots, subscription products, and one Slack thread where everyone asks whether the reviewer used the right build.

A better App Review process treats rejection patterns as release risks, not random bureaucracy.

1. Start by making the app reviewable

The first failure mode is embarrassingly simple: App Review cannot use the app.

Common causes:

1. login credentials are missing, expired, or region-locked
2. two-factor authentication blocks the demo account
3. the app requires hardware, QR codes, invitations, test data, or admin approval that was not provided
4. backend services are pointed at staging and staging is down
5. feature flags hide the submitted functionality from the review account
6. the reviewer hits an empty account and cannot reach the feature being reviewed
7. a paywall blocks review of the core behavior

This is not a philosophical dispute with Apple. It is an operational miss.

Before submitting, run the app as if you were the reviewer:

1. install the archive or TestFlight build on a clean device
2. sign in using only the credentials in App Review notes
3. follow the exact path to the submitted feature
4. verify every required server, entitlement, product, and flag is live
5. confirm the account has realistic data
6. remove anything that depends on an internal VPN, staff account, or human approval queue

If the app needs special access, explain it plainly in App Review notes. Provide credentials, steps, sample data, required attachments, and any environment constraints.

Do not write a paragraph of hope. Write instructions a tired reviewer can execute at the end of a long queue.

2. Keep metadata honest and boring

Metadata rejections happen when the App Store listing, screenshots, description, privacy answers, age rating, or review notes do not match the binary.

Common patterns:

• screenshots show screens that are not available in the submitted build
• marketing copy claims features that are behind a server flag or not shipped yet
• the app name, subtitle, or keywords lean on competitor names or irrelevant terms
• the description promises platform behavior the app cannot consistently deliver
• subscription terms are unclear or incomplete
• required disclaimers are missing for health, finance, children, contests, or regulated domains
• the support URL, privacy policy URL, or contact path is broken

The safest metadata is specific and current.

Before submission, compare the listing against the exact build:

1. Can a reviewer reach every feature shown in screenshots?
2. Are screenshots from the current UI, not an older design or unreleased feature branch?
3. Does the description describe what the app does now?
4. Are subscription prices, trial terms, renewal behavior, and cancellation language visible where needed?
5. Do privacy labels match the code, SDKs, and backend behavior in this release?
6. Are support and privacy URLs live without authentication?

This is not about making the listing timid. It is about not asking App Review to approve a promise the binary does not keep.

3. Catch crashes and broken flows before the reviewer does

A crash in review is a release process failure unless it depends on something genuinely external and unusual.

The high-risk flows are usually obvious:

• first launch and onboarding
• account creation and login
• purchase, restore, and entitlement refresh
• permissions onboarding
• primary content creation
• search, import, upload, or sync
• empty states and first-use states
• deep links from push, email, or universal links
• offline or poor-network behavior

Review devices are clean. They do not have your cached session, seeded database, previous entitlement state, friendly local network, or the simulator's generous interpretation of reality.

A practical pre-submit pass should include:

1. fresh install on a physical device
2. upgrade from the previous App Store version when persistence changed
3. clean account and existing account paths
4. denied permissions path
5. purchase restore path
6. airplane mode or poor-network path for critical screens
7. app background/foreground during onboarding or checkout
8. at least one run with production backend configuration

If the app crashes because an optional server field is missing, a receipt refresh returns slowly, or a push deep link arrives before session restoration finishes, App Review did not create the bug. It merely found the body.

4. Treat privacy as a release surface

Privacy-related rejection patterns usually come from drift.

The code changed. The SDK list changed. The backend started collecting a new field. The privacy policy was not updated. The App Store privacy labels stayed untouched because the release checklist treated them as someone else's problem.

Common privacy risks:

• missing or stale privacy policy
• privacy labels that no longer match collected data
• tracking behavior without the required consent flow
• third-party SDKs collecting data not reflected in the listing
• analytics identifiers used in ways the team has not documented
• permission prompts that request more access than the feature needs
• required reason API declarations missing from PrivacyInfo.xcprivacy
• tracking domains or SDK manifests drifting after dependency updates

The fix is to make privacy review part of release review, not a separate annual archaeological expedition.

For each release, ask:

1. Did we add or update any SDK?
2. Did we change analytics, attribution, ads, diagnostics, crash reporting, or experiments?
3. Did we add any data collection, account field, contact import, location usage, health data, photos access, or background capability?
4. Did server behavior change in a way that affects what the app collects or links to the user?
5. Did privacy labels, privacy policy, consent copy, and privacy manifests all stay aligned?

Privacy work is not complete when the code compiles. It is complete when the app, metadata, policy, SDKs, and submitted archive tell the same story.

5. Be precise with purchases and subscriptions

In-app purchase rejections tend to be expensive because they sit between product, engineering, pricing, legal copy, and App Store Connect configuration.

Common patterns:

1. digital goods or features use an external payment path when they need in-app purchase
2. purchase products are missing, not approved, unavailable in the reviewer region, or attached to the wrong app version
3. subscription terms are incomplete in the app UI
4. restore purchase is missing, hidden, or broken
5. entitlement state does not update after purchase, renewal, cancellation, grace period, or refund
6. server receipt validation fails for sandbox or review accounts
7. paywall copy implies lifetime access where the product is subscription-based
8. pricing in screenshots or copy does not match App Store Connect

The review-safe baseline is dull and effective:

• show the product being purchased
• show price and billing period from StoreKit, not hard-coded fantasy numbers
• show trial terms when there is a trial
• provide a visible restore path
• handle pending, failed, deferred, revoked, and restored transactions
• make entitlement refresh observable and retryable
• test with sandbox accounts and a clean install

For small teams, the most common mistake is treating the happy purchase path as the purchase system. It is not. App Review often exercises restore, unavailable products, sandbox delays, and account edge cases because users will too.

A paywall is release-critical infrastructure. Test it with the respect normally reserved for migrations and payroll.

6. Handle login and account rules deliberately

Authentication creates several App Review traps.

Common patterns:

• the app offers third-party social login but omits the required Apple sign-in option where the rule applies
• account creation works, but account deletion is missing, hidden, or incomplete
• the app requires login before showing anything useful without a clear reason
• the app requests personal information before explaining the product value
• demo credentials work only for the developer's region, device, or backend environment
• the review account gets blocked by email verification, SMS verification, fraud rules, or feature eligibility checks

The prevention checklist is simple:

1. Test the review account from a clean device and a non-staff network.
2. Disable or document verification paths that would block App Review.
3. Provide a fully usable demo account when login is required.
4. Keep account deletion reachable from inside the app if the app supports account creation.
5. Confirm Sign in with Apple requirements when using third-party or social login.
6. Explain any required external account, institution, subscription, hardware, or eligibility constraint in review notes.

If the reviewer cannot get past login, the rest of the release does not exist. The app may be well built, but App Review can only evaluate the product it can reach.

7. Do not ignore user-generated content obligations

Apps with user-generated content need moderation paths that are visible and functional.

For most products in this category, App Review will look for some combination of:

• reporting abusive content
• blocking users
• moderation or filtering behavior
• terms of use
• handling objectionable material
• contact or escalation paths
• safe defaults for public sharing

The exact requirements depend on the product, but the operational mistake is consistent: teams build the content feature and treat safety controls as administrative garnish.

Before submission, verify the actual user path:

1. Can a user report content from the screen where they encounter it?
2. Can a user block or mute another user where relevant?
3. Does the app explain public visibility and sharing consequences?
4. Does the backend actually receive the report?
5. Does support or moderation have enough information to act?
6. Are terms and policies reachable from the app and listing?

If UGC is central to the app, moderation is not a footer link. It is part of the product surface.

8. Watch permissions and capabilities

Permissions are another place where review failures come from mismatch.

The app asks for access. The purpose string is vague. The feature does not need the permission yet. The review account cannot reach the feature that explains why the permission is requested. The app crashes when access is denied. Now a routine release becomes a policy conversation.

High-risk areas include:

• location
• contacts
• photos and camera
• microphone
• health data
• Bluetooth
• local network
• tracking
• notifications used for sensitive or promotional behavior
• background modes

A good permission flow has three properties:

1. Context. Ask when the user is trying to use the feature, not during launch because the app is feeling needy.
2. Specificity. The purpose string explains the product reason in plain language.
3. Recovery. Denied access produces a useful fallback or settings path, not a broken screen.

Capabilities deserve the same treatment. If the app declares background modes, HealthKit, associated domains, push notifications, or sensitive entitlements, the submitted build should clearly justify them.

Do not ship broad permissions because a future roadmap might need them. App Review evaluates the app in front of them, not the product the roadmap hopes to become later.

9. Write App Review notes like an operator

App Review notes should reduce ambiguity.

Good notes include:

• demo credentials
• exact test path for the changed feature
• required data, QR codes, invite links, test accounts, or sample content
• explanation for gated, regional, hardware-dependent, or account-based behavior
• notes about in-app purchase products under review
• anything unusual about backend state, permissions, or entitlement setup
• contact details in case App Review needs clarification

Bad notes are either empty or theatrical.

A useful format:

Review path
1. Sign in with: reviewer@example.com / provided password
2. Open Settings → Subscription
3. Tap Restore Purchases
4. Open Projects → Sample Project → Export
 
Notes
- Backend is production.
- The review account has sample data and an active test entitlement.
- Camera permission is used only for document scanning in Projects → Scan.

This is not over-explaining. It is removing cheap failure modes.

If a release contains a meaningful review risk, mention it directly instead of hoping the reviewer reconstructs your product model from screenshots and implication.

10. Respond to rejection with evidence, not emotion

When a rejection arrives, do not immediately resubmit with one tiny change and a large amount of optimism.

First classify the rejection:

1. Access problem. The reviewer could not use the app or reach the feature.
2. Binary problem. The app crashed, behaved incorrectly, or shipped the wrong build.
3. Metadata problem. The listing, screenshots, privacy answers, or notes are wrong.
4. Policy problem. The app behavior conflicts with a guideline.
5. Ambiguity problem. The reviewer misunderstood the app because the app or notes did not explain the flow clearly enough.

Then collect evidence:

• exact guideline or message from Resolution Center
• submitted app version and build number
• screenshots or videos from the reviewer if provided
• server logs for the review account where privacy-safe
• crash logs or diagnostics
• App Store Connect product and metadata state
• the exact steps needed to reproduce or disprove the issue

For access, metadata, and ambiguity problems, a clear Resolution Center reply can matter as much as a binary change. For binary and policy problems, fix the app or listing and explain what changed.

Do not argue from intent. Argue from behavior.

A good reply says:

1. what was wrong
2. what changed
3. how the reviewer can verify it
4. any credentials or test path needed
5. whether a new build was uploaded

Keep it short. The reviewer does not need a novella about your architecture. They need enough information to approve or identify the remaining issue.

11. Build a pre-submit checklist that matches your app

A generic checklist is useful once. A product-specific checklist compounds.

For an iOS app with accounts, purchases, analytics, and push notifications, I would keep a checklist like this in the release process:

1. Clean install reaches the core feature.
2. Upgrade from previous App Store version works.
3. Demo account and review notes verified.
4. Backend production configuration verified.
5. App Store metadata, screenshots, support URL, and privacy policy checked.
6. Privacy labels, privacy manifests, SDK changes, and consent flows reviewed.
7. In-app purchase products, paywall, restore, and entitlement refresh tested.
8. Login, account deletion, and Sign in with Apple rules checked.
9. Permissions purpose strings and denied paths tested.
10. UGC reporting, blocking, and terms verified if relevant.
11. Crash-free smoke pass on at least one physical device.
12. Build number, version number, release notes, and App Review notes finalized.

Keep this close to the codebase or release runbook. Update it after every rejection.

That last part is important. A rejection should buy you a better system. Otherwise it was just tuition paid to discover the same hole twice.

12. The baseline I would ship

For small iOS teams, I would treat App Review readiness as a release gate with three owners:

1. Engineering owns the binary: crashes, access, purchases, permissions, backend flags, entitlements, and archive contents.
2. Product owns the experience: screenshots, onboarding, paywall clarity, feature availability, review path, and user-facing copy.
3. Operations owns the submission: metadata, review notes, compliance answers, support links, privacy policy, and App Store Connect configuration.

One person can play all three roles on a small app. The responsibilities still need to exist.

The goal is not to eliminate every possible rejection. App Review includes judgment calls, policy interpretation, market-specific rules, and occasional reviewer confusion.

The goal is to stop wasting release cycles on preventable mistakes.

Make the app accessible. Keep metadata truthful. Test the unhappy paths. Align privacy and purchases. Give App Review exact instructions. When they push back, respond with evidence and the smallest correct fix.

That will not make release day glamorous. Good. Glamour is what teams reach for when the process is weak. A strong release process is quiet, specific, and hard to derail.