Privacy Manifest — What It Is, PrivacyInfo.xcprivacy File and Requirements

What is Privacy Manifest?

Privacy Manifest is a PrivacyInfo.xcprivacy file in property list (XML) format that declares what types of data the application collects and why it uses certain APIs. Apple introduced manifests as part of an initiative to increase privacy transparency, similar to Privacy Nutrition Label, but at the code and binary level.

The main purpose of the manifest is to document the usage of so-called Required Reason API. These are API categories that can be used for device fingerprinting, therefore each usage must be accompanied by a declaration of a specific reason from Apple's approved list.

Starting from May 1, 2024, Apple rejects builds that do not contain a Privacy Manifest. This applies to both the main app targets and all embedded SDKs and dependencies. According to WWDC 2023, the manifest is mandatory for all applications distributed through the App Store.

The manifest must be present in every binary — not only in the main application but also in every framework and static library. If a third-party SDK did not provide a manifest, the developer needs to add it manually or contact the SDK vendor for an update.

Why Apple Introduced Privacy Manifest

Before manifests, developers could use extensive system APIs (access to file system, date/time, system logs) without transparent explanation of the usage purpose. This created a risk of data leakage through third-party SDKs that could collect information without the developer's knowledge.

According to Mysk Inc. (2023), many popular SDKs used APIs for device fingerprinting without explicit necessity — for example, reading uptime to determine time zone or scanning directories to collect metadata. Privacy Manifest requires declaring every such action.

In addition to Required Reason API, the manifest includes the NSPrivacyTracking section — a flag indicating whether the app uses tracking (requires ATT), and NSPrivacyCollectedDataTypes — a list of collected data types in Privacy Nutrition Label format.

Difference Between Privacy Manifest and Privacy Nutrition Label

Privacy Nutrition Label is a user-facing representation on the app page in the App Store, showing what data the app collects. Privacy Manifest is a technical file inside the binary that Apple checks automatically. If the data in the manifest does not match the labels in App Store Connect, Apple rejects the build.

Thus, the manifest is the source of truth for Apple's verification system. Privacy labels are automatically generated based on it, but the developer must keep both representations up to date. Changing the manifest after publication requires submitting a new build for review.

Structure of PrivacyInfo.xcprivacy

The PrivacyInfo.xcprivacy file uses the property list format with a root type of Dictionary. The main top-level keys are: NSPrivacyTracking (Boolean), NSPrivacyTrackingDomains (Array), NSPrivacyCollectedDataTypes (Array), NSPrivacyAccessedAPITypes (Array).

Top-Level Keys

The NSPrivacyTracking key — a boolean value indicating whether the app applies tracking (requires ATT). If true, you must also specify NSUserTrackingUsageDescription in Info.plist. The NSPrivacyTrackingDomains key — an array of domains where tracking is applied.

The NSPrivacyCollectedDataTypes key — an array of dictionaries, each describing a type of collected data: category (NSPrivacyCollectedDataType), linkage (NSPrivacyCollectedDataLinked), purpose (NSPrivacyCollectedDataTypePurposes). Purposes include: third-party advertising, analytics, product development, and content personalization.

The NSPrivacyAccessedAPITypes key — an array of dictionaries for each Required Reason API category: category (NSPrivacyAccessedAPITypeReasons) — a specific reason from Apple's approved list, and NSPrivacyAccessedAPIType — the API category identifier.

<!-- PrivacyInfo.xcprivacy -->
<?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>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>C617.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

Data Categories in NSPrivacyCollectedDataTypes

Data types are divided into several categories: contact information (name, email, phone), finances (payment data), identifiers (IDFA, User ID), usage data (logs, clicks), diagnostics (crash logs), and user content (photos, videos, files). Each category is additionally marked as "linked to user" or "not linked".

Linked means the data is tied to the user's account; not linked means the data is aggregated or anonymized. This marking affects how Apple displays the privacy label: linked data is marked yellow, not linked — green.

Which APIs Require Reasons

Apple has identified several API categories, each use of which must be accompanied by a specific reason from the approved list. A reason is a unique code, for example C617.1 or 35F9.1, which is matched to a specific purpose allowed by Apple.

Main Required Reason API Categories

The NSPrivacyAccessedAPICategoryFileTimestamp category includes APIs for accessing file timestamps (creationDate, modificationDate). Reasons: C617.1 (file synchronization), 3B52.1 (backup), 0A2A.1 (antifraud).

The NSPrivacyAccessedAPICategoryDiskSpace category includes APIs for checking free disk space (NSFileManager. Checks (NSFileManager). Reasons: E174.1 (cache management), 85F4.1 (content download), B728.1 (diagnostics).

The NSPrivacyAccessedAPICategorySystemBootTime category includes APIs for accessing system boot time (uptime). Only one reason: 35F9.1 (session time measurement for analytics). Any other usage is considered fingerprinting.

Full List of API Categories

• FileTimestamp — access to file timestamps, allowed for synchronization and backup
• DiskSpace — free space check, allowed for cache management and downloads
• SystemBootTime — uptime, allowed only for session analytics
• UserDefaults — access to UserDefaults of other apps, completely prohibited
• ActiveKeyboards — list of active keyboards, allowed for IME developers
• SystemAperture — screen cutout size, allowed for photo and AR apps

Each category has 1 to 5 approved reasons. The developer must choose the reason that most accurately matches the actual API usage. Providing an inaccurate reason may lead to build rejection or account ban.

Requirements for Third-Party SDKs

Starting from May 1, 2024, all third-party SDKs — both binary and open source — are required to include a Privacy Manifest in their package. Apple checks manifests for all dependencies, and if at least one SDK does not have a manifest, the build will be rejected.

Major SDKs (Firebase, Adjust, AppsFlyer, Facebook SDK) have already updated their packages. If your project uses a less known SDK, check its version and if necessary update it or contact the developer. A temporary workaround is to add a manifest for the SDK manually in the project, but this is not recommended due to discrepancies during updates.

How to Create Privacy Manifest in Xcode

You can create PrivacyInfo.xcprivacy through the built-in template in Xcode 15+ or manually. Let's consider both options.

Creating via Xcode 15

Xcode 15 includes a Privacy Manifest template: File → New → File → Resource → Privacy Manifest. Xcode creates a file with basic structure and fills in NSPrivacyTracking and empty arrays for API and data. After creation, you need to manually specify reasons for each Required Reason API used.

The template automatically adds the file to the main target. If the project has multiple targets (Extensions, Watch app), you need to add the manifest to each one. Xcode does not check for manifest presence in dependencies at compile time — only at the archiving stage.

// AppDelegate: manifest check at development stage
import Foundation

func validatePrivacyManifest() {
    guard let path = Bundle.main.path(
        forResource: "PrivacyInfo", ofType: "xcprivacy"
    ) else {
        print("PrivacyInfo.xcprivacy not found")
        return
    }
    guard let dict = NSDictionary(contentsOfFile: path)
    else { return }
    print("Privacy manifest loaded: \(dict.count) keys")
}

Manual Creation via XML

You can create PrivacyInfo.xcprivacy manually as a regular XML property list file. To do this, create a file named PrivacyInfo.xcprivacy, write the standard plist header, and add a root dictionary with the necessary keys. Make sure the file is added to the target (Target Membership).

The manual approach is useful when you need to add a manifest to a static library or Package Manager dependency without using the Xcode UI. After compilation, verify that the file is included in the binary using the nm command or archiving.

Validating the Manifest Before Publication

Before submitting the build to the App Store, you need to verify that the Privacy Manifest is correct and complete. Apple provides several validation tools.

Built-in Xcode Validator

When archiving a project (Product → Archive), Xcode performs manifest validation. If an error is found — missing manifest, incorrect reason, empty category — archiving fails with an error. The error log is displayed in the Issue navigator, indicating the problematic SDK and API category.

Additional validation is performed on the App Store Connect side when uploading the build. If validation fails, the build is rejected with an automatic email containing the identifier of the problematic API and recommended fix.

Command Line Validation

To automate validation, use scripts that analyze the binary for Required Reason API usage. Apple provides the libtool tool and symbol checking scripts, but the community has developed more convenient utilities.

# Searching for FileTimestamp API usage in binary
nm MyApp.app/MyApp | grep "NSFileCreationDate"

# Checking PrivacyInfo.xcprivacy presence in the application
find MyApp.app -name "*.xcprivacy"

Common Validation Errors

The most common error is a missing manifest in one of the SDKs. Even if the main target contains a manifest, Apple checks each binary individually. The second most common is an incorrect reason code — using a reason for one API category with an API from another category.

The third error is over-declaration of APIs that are not actually used. Developers add all possible reasons "just in case," which raises suspicion from Apple reviewers. Only add categories that are actually used. Use the Xcode static analyzer to verify.