Axiom App Store Ref

App Store Submission Reference

Overview

Complete reference for every App Store submission requirement:

• Part 1 — Required metadata fields (descriptions, screenshots, keywords, App Review info)
• Part 2 — Privacy requirements (manifest schema, nutrition labels, ATT, Required Reason APIs)
• Part 3 — App Review Guidelines quick reference (all sections 1-5)
• Part 4 — Age rating system (5-tier, capabilities, regional variations)
• Part 5 — Export compliance (encryption decision tree)
• Part 6 — Account and authentication requirements (deletion, SIWA)
• Part 7 — Monetization and IAP submission pipeline
• Part 8 — EU-specific compliance (DSA trader status)
• Part 9 — Build upload and processing
• Part 10 — WWDC25 changes (draft submissions, accessibility labels, tags)

When to Use This Skill

Use when

• Looking up specific metadata field requirements or character limits
• Checking App Review guideline numbers for a specific topic
• Verifying privacy manifest schema fields or Required Reason API categories
• Understanding age rating tiers and new capability declarations
• Checking EU compliance requirements for DSA trader status
• Understanding IAP submission pipeline and review flow
• Preparing builds for upload (SDK requirements, encryption, signing)

Do NOT use when

• Deciding if your app is ready to submit (use app-store-submission)
• Troubleshooting a rejection (use app-store-diag)
• Implementing in-app purchases (use storekit-ref)
• Writing privacy manifest code (use privacy-ux)
• Auditing accessibility compliance (use accessibility-diag)

Related Skills

• app-store-submission — Discipline skill with pre-flight checklist and workflow
• app-store-diag — Rejection troubleshooting and appeal guidance
• privacy-ux — Privacy manifest implementation, ATT UX, permission requests
• storekit-ref — StoreKit 2 API reference for IAP implementation
• accessibility-diag — Accessibility compliance scanning and VoiceOver testing

Key Terminology

Part 1: Required Metadata Fields

Immutable Fields (Cannot Change After Creation)

These fields are locked once set. Choose carefully:

• Bundle ID — must match Xcode project exactly
• SKU — internal identifier, never shown to users
• IAP Product ID — cannot be changed or reused after creation
• Subscription Duration — locked after subscription is created

App Information

Visual Assets

Screenshot Requirements

Format: .jpeg, .jpg, .png. Min 1, max 10 per device size per locale.

Fallback: Provide highest resolution only — App Store auto-scales to smaller sizes. Required: 6.9" or 6.5" for iPhone, 13" for iPad.

Screenshots must show the app in actual use. Not permitted: title art alone, login screens, splash screens, or screens from other platforms. Cannot update screenshots on an approved version — must create a new version.

App Preview Video Specifications

Gotchas: Processing can take up to 24 hours — do not submit for review immediately after uploading previews. All audio tracks must be enabled (disabled tracks cause rejection). Previews always appear before screenshots on the product page.

App Icon Requirements

App Review Information

Metadata Rules (Guideline 2.3)

• App names must be unique, max 30 characters
• Keywords must not include trademarked terms, popular app names, or pricing terms ("free", "sale")
• Screenshots must show the app in use, not just marketing art
• Icons, screenshots, and previews must be appropriate for a 4+ rating even if the app is rated higher
• "For Kids" and "For Children" are reserved for the Kids category
• No other mobile platform names or imagery in screenshots (no Android phones, Windows logos)
• Metadata must accurately reflect app functionality; misleading metadata is grounds for rejection

Localization Requirements

When localizing, provide screenshots that match the localized UI. Reviewers check that screenshots accurately represent the app in each locale.

Category Selection

Available categories: Books, Business, Developer Tools, Education, Entertainment, Finance, Food & Drink, Games, Graphics & Design, Health & Fitness, Lifestyle, Magazines & Newspapers, Medical, Music, Navigation, News, Photo & Video, Productivity, Reference, Shopping, Social Networking, Sports, Travel, Utilities, Weather.

Part 2: Privacy Requirements

Privacy Policy (Guideline 5.1.1(i))

Required in BOTH locations:

1. App Store Connect metadata (Privacy Policy URL field)
2. Within the app itself (accessible from settings or equivalent)

The privacy policy must identify:

• What data is collected and by what means
• All uses of collected data
• Third-party sharing practices
• Data retention and deletion policies
• How users can revoke consent

Privacy Manifest Schema (PrivacyInfo.xcprivacy)

<!-- Top-level keys -->
NSPrivacyTracking              <!-- Boolean: Does app track users? -->
NSPrivacyTrackingDomains       <!-- Array<String>: Domains used for tracking -->
NSPrivacyCollectedDataTypes    <!-- Array<Dictionary>: Data collected -->
NSPrivacyAccessedAPITypes      <!-- Array<Dictionary>: Required Reason APIs -->

NSPrivacyCollectedDataTypes Entry

Each dictionary in the array contains:

NSPrivacyAccessedAPITypes Entry

Each dictionary in the array contains:

Complete PrivacyInfo.xcprivacy Example

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyTracking</key>
    <false/>
    <key>NSPrivacyTrackingDomains</key>
    <array/>
    <key>NSPrivacyCollectedDataTypes</key>
    <array>
        <dict>
            <key>NSPrivacyCollectedDataType</key>
            <string>NSPrivacyCollectedDataTypeEmailAddress</string>
            <key>NSPrivacyCollectedDataTypeLinked</key>
            <true/>
            <key>NSPrivacyCollectedDataTypeTracking</key>
            <false/>
            <key>NSPrivacyCollectedDataTypePurposes</key>
            <array>
                <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
            </array>
        </dict>
    </array>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

API Category Identifiers

Generating Aggregate Privacy Report

Xcode > Product > Archive > Generate Privacy Report

This produces a PDF summarizing privacy manifests from your app and all embedded frameworks.

Privacy manifest gotchas:

• Custom string values for NSPrivacyCollectedDataType or NSPrivacyCollectedDataTypePurposes are silently rejected by Xcode — must use Apple's predefined constants
• iOS 17 automatically blocks connections to declared tracking domains when user denies tracking
• IP address collection must be declared (as location, device ID, or diagnostics)
• Web view data collection must be declared
• You are responsible for ALL data collected by third-party SDKs in your app
• Some SDKs default to tracking unless explicitly disabled — creates unintentional tracking
• Fingerprinting is NEVER allowed, regardless of ATT permission
• Since May 1, 2024: missing required-reason API declarations cause automatic rejection (no human review)

Required Reason API Categories

App Privacy Details (Nutrition Labels)

Data Type Categories

Purpose Categories

Tracking and Collection Definitions

"Collected" means data is transmitted off-device and accessible beyond what is needed to service the current request. On-device-only processing is NOT collection.

"Tracking" means:

• Linking user/device data from your app with third-party data for advertising or measurement, OR
• Sharing user/device data with a data broker

App Tracking Transparency (ATT)

Required if your app "tracks" per Apple's definition above.

• Add NSUserTrackingUsageDescription to Info.plist (explains why tracking is needed)
• Call ATTrackingManager.requestTrackingAuthorization() before tracking
• Respect the result:
  • .authorized — User granted permission to track
  • .denied — User denied tracking; do not track
  • .notDetermined — User has not yet been asked
  • .restricted — Device-level restriction prevents tracking

Request at a contextually appropriate moment, not at first launch.

Common Purpose Strings (NS*UsageDescription)

These Info.plist keys must be present for each system permission your app requests:

Missing purpose strings cause immediate rejection. Purpose string text must clearly explain why the permission is needed in the context of your app's functionality.

Third-Party SDK Privacy Manifests

Apple maintains a list of commonly used SDKs that require privacy manifests. Starting spring 2024, if your app includes these SDKs without privacy manifests, it will be flagged during submission.

Third-party SDKs should include their own PrivacyInfo.xcprivacy in their framework bundle. The aggregate privacy report combines all manifests from your app and embedded frameworks.

If a third-party SDK does not include a privacy manifest, you must declare its data collection in your app's privacy manifest.

Part 3: App Review Guidelines Quick Reference

For the complete guideline index (Sections 1-5), see references/app-review-guidelines.md.

Most Common Rejection Reasons

See references/app-review-guidelines.md for the full top-10 rejection causes table with percentages.

App Review Timeline

Review times increase during holidays and major iOS release periods. Plan submissions accordingly.

Part 4: Age Rating System

Five-Tier Rating System (Updated January 31, 2026)

Capability Declarations (New, WWDC25)

Apps must declare if they include these capabilities:

These declarations appear alongside the age rating on the App Store product page, giving parents and users additional transparency.

Regional Variations

Age ratings map differently across regions:

The age rating questionnaire automatically generates the appropriate regional ratings based on your answers.

Age Rating Best Practices

• Answer the questionnaire conservatively; under-rating leads to rejection
• If your app accesses unrestricted web content (WebView without content filter), it will be rated 16+ minimum
• UGC apps typically need 13+ minimum due to moderation requirements
• Simulated gambling (even without real money) requires at least 9+
• Realistic violence in gameplay requires at least 13+

Age Rating Questionnaire Topics

The questionnaire covers these content categories:

The system automatically calculates your app's age rating across all regions based on your answers.

Part 5: Export Compliance

Three-Tier Encryption System

Encryption Decision Tree

Does your app use encryption?
├── No → ITSAppUsesNonExemptEncryption = NO → Done
├── Only Apple OS encryption (HTTPS, Keychain, CryptoKit)?
│   ├── Yes → ITSAppUsesNonExemptEncryption = NO → Done
│   │         (May need annual BIS self-classification report)
│   └── No → Industry-standard algorithm (AES, RSA, etc.)?
│       ├── Yes → ITSAppUsesNonExemptEncryption = YES
│       │         French declaration if distributing in France
│       │         Upload docs → receive ITSEncryptionExportComplianceCode
│       └── No (custom/proprietary) →
│           ITSAppUsesNonExemptEncryption = YES
│           US CCATS required (~2 business days)
│           French declaration if France
│           Upload docs → receive ITSEncryptionExportComplianceCode

Info.plist Keys

<!-- Most apps: only Apple OS encryption -->
<key>ITSAppUsesNonExemptEncryption</key>
<false/>

<!-- Apps with non-exempt encryption (bypasses questionnaire on future submissions) -->
<key>ITSAppUsesNonExemptEncryption</key>
<true/>
<key>ITSEncryptionExportComplianceCode</key>
<string>YOUR_COMPLIANCE_CODE</string>

Setting ITSAppUsesNonExemptEncryption in Info.plist skips the encryption questionnaire on every submission.

Exempt Encryption Uses

No documentation needed:

• HTTPS/TLS (URLSession, Network.framework, WKWebView)
• Secure Enclave, Keychain, biometric auth
• CryptoKit, Security.framework per Apple docs
• Password hashing (bcrypt, scrypt, PBKDF2)

Non-Exempt Encryption Uses

Documentation required:

• Custom encryption algorithms
• OpenSSL, libsodium for non-standard purposes
• End-to-end encrypted messaging
• VPN implementations
• Custom DRM systems

France-Specific

Import/export controlled by ANSSI. Banking and medical apps are exempt. Applies to: secure storage, secure communications, security/antivirus apps.

Part 6: Account and Authentication

Account Deletion (Required Since June 2022)

Apps that support account creation must offer account deletion. Requirements:

Sign in with Apple Token Revocation

// Server-side: revoke SIWA tokens when account deleted
// POST https://appleid.apple.com/auth/revoke
// Parameters: client_id, client_secret, token, token_type_hint

Failing to revoke SIWA tokens during account deletion is a common rejection reason.

Sign in with Apple (Guideline 4.8)

Required when: Your app offers ANY third-party or social login option (Google, Facebook, Twitter, email/password via third-party provider).

Exceptions — SIWA not required when

• App is for company employees only (internal enterprise app)
• App is for education or enterprise with existing institutional auth
• App uses government or industry-backed citizen ID systems
• App is a client for a specific third-party service (e.g., Gmail app, Slack)

When SIWA is required, it must be offered as an equally prominent option alongside other sign-in methods. It cannot be hidden or given less visual weight.

Account Deletion Implementation Checklist

Apple specifically rejects apps that:

• Require users to call a phone number to delete their account
• Require users to send an email to request deletion
• Only offer account deactivation (hiding profile) instead of full deletion
• Don't handle SIWA token revocation

Part 7: Monetization and IAP

IAP Submission Pipeline

In-app purchases have a separate review process from app submissions:

Required IAP Metadata

IAP Status Flow

Missing Metadata → Ready to Submit → Waiting for Review → In Review → Approved
                                                                    → Rejected

IAP must be in "Ready to Submit" status before it can be included in an app submission.

Subscription Rules (Guideline 3.1.2)

Loot Boxes (Guideline 3.1.1)

Apps offering loot boxes or random item mechanics must disclose the odds of receiving each type of item before purchase.

External Payment Eligibility

Apps in these categories may accept payment outside the IAP system.

Subscription Group Architecture

Subscription Pricing

Subscription Restore Purchases

All subscription apps must implement Restore Purchases functionality. This is tested during App Review. Implement via:

try await AppStore.sync()

If Restore Purchases is missing or non-functional, the app will be rejected.

Free Trial Best Practices

Part 8: EU-Specific Compliance

Digital Services Act (DSA) Trader Status

Applies to: ALL apps distributed in the EU (27 member states)

Timeline: Since February 17, 2025, apps without declared trader status are subject to removal from the EU App Store.

What is Trader Status?

A self-assessment: are you acting as a "trader" (selling goods/services to EU consumers) or a non-trader (hobby, open-source, non-commercial)? Apple cannot determine this for you.

Trader Requirements

If you declare as a trader, you must provide:

This contact information is displayed on your EU product page.

Declaring in App Store Connect

App Store Connect > Users and Access > Developer Profile > Trader Status

Select your trader status for each app. If you have both paid and free apps, each app may have a different trader classification.

EU Alternative Distribution

Under the Digital Markets Act (DMA), Apple allows alternative app distribution in the EU:

• Alternative app marketplaces
• Web distribution (notarized apps)
• Alternative payment processing

These require separate business terms (Alternative Terms Addendum) and additional compliance steps. See Apple's EU developer documentation for details.

EU 27 Member States

Apps distributed in any of these territories require DSA compliance:

Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden.

If your app is available in "All Territories" (the default), it is available in the EU and DSA compliance is required.

Part 9: Build Upload and Processing

Upload Methods

Build Identifiers

Build Selection

• Only one build can be selected per version
• Build selection can be changed until the version is submitted for review
• "Missing Compliance" status blocks build selection until export compliance questions are answered

SDK Requirements

Apps built with outdated SDKs will be rejected after the effective date for new submissions. Existing apps on the store are not affected until they submit an update.

Build Processing

After upload, Apple processes your build:

1. Upload — Binary transferred to Apple (5-30 minutes depending on size)
2. Processing — Apple validates binary, runs automated checks (15-60 minutes)
3. Available — Build appears in App Store Connect, ready for TestFlight or submission
4. Email notification — Sent when processing completes or fails

Common processing failures:

• Missing required architectures (arm64 required)
• Invalid provisioning profile or signing identity
• Missing privacy manifest for third-party SDKs on Apple's list
• Info.plist missing required keys
• Binary too large (OTA download limit: 200 MB over cellular)

IPv6 Compatibility

All apps must work on IPv6-only networks. Apple's review environment uses IPv6. Common issues:

• Hard-coded IPv4 addresses
• Using low-level socket APIs instead of high-level networking
• Third-party SDKs with IPv4-only code

Use URLSession or Network.framework to ensure IPv6 compatibility automatically.

App Thinning and Bitcode

Entitlements and Capabilities

Certain features require entitlements configured in Xcode and provisioning profiles:

TestFlight Submission

TestFlight readiness checklist:

• Internal tester group exists (required before creating external groups)
• Beta App Description set (can differ from production)
• Feedback email configured
• "What to Test" notes written for each external group
• Export compliance answered (required for beta builds too)
• Demo credentials included (if login required)
• First external build: expect full App Review (guideline compliance checked)

Gotchas:

• Builds uploaded as "TestFlight Internal Only" from Xcode/Xcode Cloud can only go to internal groups
• Managed Apple Accounts (School/Business Manager) cannot be testers
• Public link tester cap is configurable (1-10,000) per link
• Builds remain testable even after the app goes live on the App Store
• Developer can manually expire builds before 90 days

Part 10: WWDC25 Changes

Draft Submissions (WWDC 2025-328)

Group multiple items into a single draft submission:

• App version + new IAPs + product page changes
• Review everything together instead of separate submissions
• Draft state: prepare items over time, submit when ready

Reusable Build Numbers on Failure

When a build is rejected due to metadata issues (not binary issues), you can reuse

…(truncated)