app-store-review

# App Store Review Preparation

Catch App Store rejection risks before submission. Treat policy, SDK, privacy, entitlement, payment, and metadata checks as current release evidence rather than durable facts.

## Contents

- [Top Rejection Reasons and How to Avoid Them](#top-rejection-reasons-and-how-to-avoid-them)
- [PrivacyInfo.xcprivacy -- Privacy Manifest Requirements](#privacyinfoxcprivacy-privacy-manifest-requirements)
- [Data Use, Sharing, and Privacy Policy (Guideline 5.1.2)](#data-use-sharing-and-privacy-policy-guideline-512)
- [In-App Purchase and StoreKit Rules (Guideline 3.1.1)](#in-app-purchase-and-storekit-rules-guideline-311)
- [HIG Compliance Checklist](#hig-compliance-checklist)
- [App Tracking Transparency (ATT)](#app-tracking-transparency-att)
- [EU Digital Markets Act (DMA) Considerations](#eu-digital-markets-act-dma-considerations)
- [Entitlements and Capabilities](#entitlements-and-capabilities)
- [Submission Workflow](#submission-workflow)
- [Metadata Best Practices](#metadata-best-practices)
- [Appeal Process](#appeal-process)
- [Common Mistakes](#common-mistakes)
- [Review Checklist](#review-checklist)
- [References](#references)

Start every audit by fetching the current App Review Guidelines, Upcoming Requirements, screenshot specifications, required-reason API documentation, and applicable storefront/entitlement payment rules. Record the checked date and source beside each release blocker. Then archive-build and validate the exact submission, separate blockers from cleanup, fix one class of evidence mismatch, and rerun the same checks against the rebuilt archive.

For prompts about keywords, screenshot captions, product-page metadata, or metadata rejection risk, answer from a compliance angle and explicitly defer keyword research, ranking strategy, conversion optimization, screenshot ordering, and A/B testing to `app-store-optimization`. Keep App Review metadata guidance limited to accuracy, field limits, misleading-content risk, and screenshot compliance. Load the dated format, screenshot, and toolchain facts from [Current Release Requirements](references/review-checklists.md#current-release-requirements).

For full submission readiness audits, separate blocking upload/review issues from ordinary cleanup. Cross-check privacy manifests, App Store privacy nutrition labels, privacy policy, ATT state, runtime network behavior, and SDK behavior against each other; the declarations and observed behavior must align.

### Blocking Submission Checks

Escalate these as blockers before ordinary cleanup:

- The archive misses the current Xcode or platform SDK upload floor
- Unresolved privacy evidence mismatches; reconcile them with the [PrivacyInfo.xcprivacy requirements](#privacyinfoxcprivacy-privacy-manifest-requirements)
- Payment paths that fail the [StoreKit rules](#in-app-purchase-and-storekit-rules-guideline-311)
- Missing screenshot sets required by the current App Store Connect specification
- Review access that fails the Guideline 2.1 completeness evidence below

## Top Rejection Reasons and How to Avoid Them

| Guideline risk | Release evidence |
|---|---|
| 2.1 completeness | No placeholders, broken/empty flows, inaccessible hardware-only features, or login gates without working demo credentials and review notes. |
| 2.3 metadata | App name, category, description, keywords, and screenshots accurately represent the submitted binary and actual UI. |
| 4.2 minimum functionality | The app provides meaningful app-specific value beyond a thin website or trivial duplication of system behavior. |
| 2.5.1 software requirements | Archive uses public APIs and does not download code that changes reviewed functionality outside documented exceptions. |

Verify these against the current guidelines and the exact archive; do not carry version or screenshot requirements forward from an older release checklist.

## PrivacyInfo.xcprivacy -- Privacy Manifest Requirements

A privacy manifest is required when your app code, an executable, a dynamic library, or a third-party SDK uses Apple's required-reason API categories or declares collected data/tracking behavior.

**See:** [references/privacy-manifest.md](references/privacy-manifest.md) for the full structure, reason codes, and checklists.

### Summary

- Required-reason API categories are file timestamps, system boot time, disk space, active keyboards, and UserDefaults; each requires an approved reason code when used.
- Before final submission, re-check Apple's current required-reason API documentation and do not choose broad, convenient, or invented reason codes.
- Required-reason API declarations belong in the bundle that contains the code using the API; every app target, executable, dynamic library, framework, or SDK bundle containing manifest-relevant code needs the matching manifest declarations.
- Each SDK, executable, or dynamic library that collects data, uses required-reason APIs, enables data collection/tracking, or contacts tracking domains needs manifest attention in the bundle containing that code; SDK code cannot rely on the host app's manifest to report the SDK's own usage.
- Manifest declarations must match App Store privacy nutrition labels, SDK behavior, and the app's presented functionality.

## Data Use, Sharing, and Privacy Policy (Guideline 5.1.2)

- A privacy policy URL must be set in App Store Connect AND accessible within the app
- The privacy policy must accurately describe what data you collect, how you use it, and who you share it with
- App Store privacy nutrition labels must match your actual data collection practices
- Privacy labels, privacy manifests, SDK disclosures, and runtime behavior should tell the same story

## In-App Purchase and StoreKit Rules (Guideline 3.1.1)

Digital goods, features, subscriptions, virtual currency, ad removal, and digital tips generally require IAP unless a current guideline exception, storefront rule, or approved entitlement applies. Physical goods and real-world