Privacy Manifest Validation: The Complete iOS Guide

TL;DR

Since May 2024, Apple requires every iOS app and third-party SDK to ship a PrivacyInfo.xcprivacy file, a structured property list that declares exactly which privacy-sensitive APIs your code touches and why. Miss one declaration and your App Store submission gets rejected. This guide walks you through the file structure, every required reason API category, how to audit your own app, and the most common mistakes that trip up even experienced teams.

What Is a Privacy Manifest and Why Apple Requires It

A privacy manifest is a file named PrivacyInfo.xcprivacy that lives inside your app bundle (or inside each third-party SDK). It is a standard Apple property list (plist) that answers four questions:

1. Does your app track users? (as defined by App Tracking Transparency)
2. Which domains does it contact for tracking?
3. Which privacy-sensitive APIs does it call, and for what reason?
4. What types of data does it collect, and how is that data used?

Apple introduced privacy manifests at WWDC 2023 (session "Get started with privacy manifests") and began enforcing them for all App Store submissions on May 1, 2024. The motivation is straightforward: Apple wants machine-readable, auditable declarations of privacy behavior, not just the honor-system nutrition labels developers fill in manually on App Store Connect.

When you archive your app in Xcode, it automatically aggregates the privacy manifests from your app target and every bundled SDK into a single Privacy Report. That report feeds into your App Store privacy nutrition label and is what Apple's automated review checks against your binary.

If the report is missing entries, incomplete, or contradicts what your binary actually does, you get a warning email starting with ITMS-91053 or ITMS-91055. The email is the early warning; the block comes when you submit that build for review.

The PrivacyInfo.xcprivacy File Structure

The file is a standard XML plist with four top-level keys. Here is a complete, annotated 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>

    <!-- 1. Does this app/SDK track users? -->
    <key>NSPrivacyTracking</key>
    <false/>

    <!-- 2. Domains used for tracking (only if NSPrivacyTracking is true) -->
    <key>NSPrivacyTrackingDomains</key>
    <array/>

    <!-- 3. Required reason APIs this code accesses -->
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>C617.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
    </array>

    <!-- 4. Types of data this app/SDK collects -->
    <key>NSPrivacyCollectedDataTypes</key>
    <array>
        <dict>
            <key>NSPrivacyCollectedDataType</key>
            <string>NSPrivacyCollectedDataTypeUserID</string>
            <key>NSPrivacyCollectedDataTypeLinked</key>
            <true/>
            <key>NSPrivacyCollectedDataTypeTracking</key>
            <false/>
            <key>NSPrivacyCollectedDataTypePurposes</key>
            <array>
                <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
            </array>
        </dict>
    </array>

</dict>
</plist>

How to create this file in Xcode: Go to File > New > File, search for "App Privacy," select the privacy manifest template, and add it to your app target. Xcode gives you a visual editor, but understanding the raw XML matters when debugging CI pipelines or reviewing SDK manifests.

Required Reason APIs: What They Are and How to Declare Them

Apple designates certain system APIs as "required reason APIs" because they can be used for fingerprinting (identifying a device without the user's consent). If your code calls any of these APIs, you must declare why using one of Apple's pre-approved reason codes.

There are five categories:

File Timestamp APIs (NSPrivacyAccessedAPICategoryFileTimestamp)

APIs like NSFileCreationDate, NSFileModificationDate, and NSURLContentModificationDateKey. Common reason codes:

Code	When to use it
C617.1	Accessing timestamps of files inside your own app container, app group container, or CloudKit container
DDA9.1	Displaying file timestamps to the user (information cannot be sent off-device)
3B52.1	Accessing timestamps for files the user explicitly selected (e.g., via a document picker)
0A2A.1	Third-party SDK wrapper that only accesses timestamps when the host app calls your API

System Boot Time APIs (NSPrivacyAccessedAPICategorySystemBootTime)

APIs like systemUptime and mach_absolute_time. Reason codes:

Code	When to use it
35F9.1	Measuring elapsed time between events within the app, or enabling timers. Derived timing data may be sent off-device, but raw boot time may not.
8FFB.1	Calculating or generating timestamps, such as for logging purposes
3D61.1	Including boot time in an optional, user-initiated bug report; the value must not leave the device except as part of that report

Disk Space APIs (NSPrivacyAccessedAPICategoryDiskSpace)

APIs like volumeAvailableCapacityKey and NSFileSystemFreeSize. Common reason codes:

Code	When to use it
E174.1	Checking whether there is enough disk space to write files, or cleaning up when space is low. The app must visibly react to disk space levels.
85F4.1	Displaying disk space to the user (in data units or media-time units). Cannot be sent over the internet.
7D9E.1	Including disk space info in an optional, user-initiated bug report
B728.1	Health-related research apps using HealthKit

User Defaults APIs (NSPrivacyAccessedAPICategoryUserDefaults)

The UserDefaults API. Common reason codes:

Code	When to use it
CA92.1	Reading/writing data that is only accessible to your own app (the most common case)
1C8F.1	Reading/writing data shared between apps, extensions, and App Clips in the same App Group
C56D.1	Third-party SDK reading data written by the host app
AC6B.1	Accessing managed app configuration (com.apple.configuration.managed)

Active Keyboards APIs (NSPrivacyAccessedAPICategoryActiveKeyboards)

APIs that list installed or active keyboards.

Code	When to use it
3EC4.1	The app itself is a custom keyboard app determining if it is the active keyboard
54BD.1	Presenting the correct customized UI based on active keyboards; the data must not leave the device

Tracking Domains and NSPrivacyTracking

Two keys work together to declare tracking behavior:

NSPrivacyTracking is a Boolean. Set it to true if your app or SDK uses data for tracking as Apple defines it: linking data collected from your app with data from other companies' apps, websites, or offline properties for advertising or data brokering purposes.

NSPrivacyTrackingDomains is an array of domain strings. If NSPrivacyTracking is true, list every domain your code contacts for tracking. If the user has not granted ATT (App Tracking Transparency) permission, iOS will automatically block network requests to these domains.

<key>NSPrivacyTracking</key>
<true/>
<key>NSPrivacyTrackingDomains</key>
<array>
    <string>analytics.example.com</string>
    <string>ads.example.com</string>
</array>

A practical note: even if you set NSPrivacyTracking to false, we recommend still including the NSPrivacyTrackingDomains key with an empty array (house practice, not an Apple requirement). It keeps the manifest complete and avoids ambiguity.

Step-by-Step: How to Audit Your App's Privacy Manifest

Here is a repeatable process you can run before every submission.

Step 1: Generate the Privacy Report in Xcode

1. Select Product > Archive to build your release archive
2. In the Organizer, right-click your archive
3. Choose Generate Privacy Report
4. Xcode produces a PDF listing every privacy manifest from your app and all embedded SDKs

This is the same report Apple's review system generates. If something is missing here, it will be missing during review.

Step 2: Inventory your required reason API usage

Search your codebase for these patterns:

# File timestamps
grep -rn "NSFileCreationDate\|NSFileModificationDate\|contentModificationDateKey\|NSURLCreationDateKey" .

# System boot time
grep -rn "systemUptime\|mach_absolute_time\|ProcessInfo.*systemUptime" .

# Disk space
grep -rn "volumeAvailableCapacity\|NSFileSystemFreeSize\|NSFileSystemSize" .

# User defaults
grep -rn "UserDefaults\|NSUserDefaults\|\[NSUserDefaults" .

# Active keyboards
grep -rn "activeInputModes\|UITextInputMode" .

Cross-reference every hit against your NSPrivacyAccessedAPITypes declarations.

Step 3: Audit third-party SDK manifests

For each SDK in your project:

1. Check if it includes its own PrivacyInfo.xcprivacy file
2. If it does not, check the SDK's release notes or GitHub issues, the vendor may have released an updated version
3. If the SDK is abandoned and has no manifest, you may need to add the declarations to your app-level manifest (though Apple's guidance says each SDK should have its own)

Step 4: Verify tracking domain declarations

If your app uses any analytics, advertising, or attribution SDKs:

1. Run the app with a network proxy (Charles Proxy or mitmproxy)
2. Filter for domains contacted during a session
3. Identify which domains are used for tracking vs. functional purposes
4. Ensure tracking domains are listed in NSPrivacyTrackingDomains

Step 5: Cross-check collected data types

Compare your NSPrivacyCollectedDataTypes entries against what you declared on App Store Connect. They should match. Discrepancies are a review flag.

Step 6: Validate the plist syntax

# Validate the XML is well-formed
plutil -lint PrivacyInfo.xcprivacy

# Convert to readable JSON for easier review
plutil -convert json -o - PrivacyInfo.xcprivacy | python3 -m json.tool

Common Mistakes That Trigger App Review Rejection

These are the patterns that account for the majority of privacy manifest rejections.

1. Missing manifest entirely. Your app calls UserDefaults (almost every app does) but has no PrivacyInfo.xcprivacy at all. This triggers ITMS-91053.

2. Outdated third-party SDKs. Your app's manifest is fine, but you are bundling an analytics SDK from 2023 that predates the requirement. Update the SDK or verify it includes its own manifest.

3. Invalid reason codes. Declaring reason code CA92.1 for a FileTimestamp API category. Reason codes are specific to their category, you cannot mix them.

4. Missing reason codes. You declare the API category but leave the reasons array empty, or omit a reason that your code actually requires.

5. Adding SDK declarations to your app manifest. Apple's guidance is explicit: do not add the privacy practices of an SDK to your app's manifest. Each SDK should carry its own. Xcode merges them automatically.

6. Declaring tracking as false while using tracking domains. If you list domains in NSPrivacyTrackingDomains but set NSPrivacyTracking to false, Apple sees a contradiction.

7. Not updating after adding new features. You add a file-management feature that reads modification dates, but forget to add the FileTimestamp API declaration. The manifest drifts out of sync with the binary.

How to Handle Third-Party SDK Privacy Manifests

Third-party SDKs are where most privacy manifest pain originates. Here is how to manage them.

Check Apple's list of commonly-used SDKs. Apple publishes a list of third-party SDKs that are expected to include their own privacy manifests. If your SDK is on that list and does not include one, your submission may be rejected regardless of what your own manifest says.

Pin SDK versions that include manifests. When you update a dependency, verify the new version still includes PrivacyInfo.xcprivacy. Some package managers strip resource bundles during integration.

Audit with the privacy report. After archiving, the Xcode Privacy Report shows manifests per SDK. If an SDK is missing from the report, its manifest did not get bundled correctly.

For SDKs you cannot update, consider:

• Forking and adding a manifest yourself
• Filing an issue with the maintainer and linking to Apple's documentation
• Replacing the SDK with an actively maintained alternative

Use automated scanning. Manually auditing manifests across dozens of dependencies does not scale. Tools like AppCompliance can continuously scan your app binary and its embedded SDKs, flag missing or incomplete privacy manifests, and alert you before you submit to App Store review. This turns a manual, error-prone checklist into a repeatable, automated gate in your CI/CD pipeline. The same idea extends to your whole dependency tree in our guide to auditing third-party SDKs.

FAQ

Do I need a privacy manifest if my app does not collect any data?

Yes. If your app calls any required reason API, and nearly every app calls UserDefaults at minimum, you need a privacy manifest declaring that usage. The manifest is not only about data collection; it is about API access.

What happens if my privacy manifest is incomplete?

Apple sends a warning email with error codes like ITMS-91053 (missing API declaration) or ITMS-91055 (invalid API reason declaration); the email is the early warning, and the block comes when you submit the build for review. You will need to fix the manifest and resubmit, which adds days to your release cycle.

Do SwiftUI apps need a privacy manifest?

Yes. SwiftUI does not exempt you from privacy manifest requirements. SwiftUI apps still use UserDefaults, file APIs, and other required reason APIs under the hood.

Can I have multiple privacy manifests in one app?

Yes, and you should. Your app target has its own manifest, and each third-party SDK or framework should include its own. Xcode merges them into one Privacy Report at archive time.

Do privacy manifests apply to macOS, watchOS, and tvOS apps?

The required reason API declaration applies to iOS, iPadOS, tvOS, watchOS, and visionOS. Apple's current documentation does not list macOS among the platforms that must declare required reason API usage, so a Mac app is not held to the same declaration rule as its iOS counterpart today. Treat that as a platform detail worth re-checking each year, since Apple has expanded this requirement steadily since it started.

How often should I re-audit my privacy manifest?

At minimum, before every App Store submission. Ideally, audit as part of your CI pipeline so that any new API usage is caught before it reaches code review.

Privacy manifests are not going away. Apple is expanding their scope, not reducing it. Building a solid audit process now saves you from scrambling with every new requirement. Whether you audit manually or automate the process with a tool like AppCompliance, the key is making privacy validation a first-class step in your release workflow, not an afterthought. For the iOS road ahead, see our WWDC 2026 compliance preview.