Does every app need a privacy manifest?

Every app that uses a required-reason API or includes an SDK from Apple's commonly-used list needs one, which in practice is nearly every app that ships with third-party dependencies. Even an app with no dependencies usually reads UserDefaults, which is a required-reason category, so writing a manifest is the safe default rather than an exception.

What is NSPrivacyTrackingDomains, and can it break my app?

It lists the domains a bundle uses for tracking, and unlike the other keys it is enforced on the device: when the bundle declares tracking and the user has not granted App Tracking Transparency permission, requests to those hosts fail. Listing a domain that also serves link resolution, content or configuration takes that functionality down for every user who declined the prompt.

Why was my app rejected with ITMS-91053?

Because the build calls an API in a required-reason category — file timestamps, system boot time, disk space, active keyboards or user defaults — without a matching NSPrivacyAccessedAPITypes entry and approved reason code. The call is frequently inside a dependency rather than your own code, so check the privacy report from the Xcode Organizer to find which bundle is responsible.

Do third-party SDKs need their own privacy manifests?

Yes, and SDKs on Apple's commonly-used list must additionally be cryptographically signed by their author. Manifests do not inherit: yours does not cover a dependency, and a dependency without one leaves a gap that is attributed to your submission. If a vendor has not shipped a manifest and signature, the practical options are updating or replacing the dependency.

Glossary/iOS platform and privacy

Privacy Manifest

Definition

A privacy manifest is a PrivacyInfo.xcprivacy property list inside an app or SDK that declares the data it collects, the domains it uses for tracking, and its reasons for calling APIs Apple designates as requiring one.

Apple made manifests a submission requirement for apps that include any SDK on its commonly-used list, alongside a rule that those SDKs must be cryptographically signed by their authors. For anyone shipping an attribution or deep linking SDK this is not paperwork: an incomplete manifest is an automated App Store rejection, and a wrong NSPrivacyTracking flag can break your network requests at runtime.

What the file contains

It is a property list named PrivacyInfo.xcprivacy, added to the app target's bundle resources, or shipped inside an SDK's own bundle. Xcode aggregates every manifest in the app and its dependencies into the privacy report you attach at submission.

PrivacyInfo.xcprivacy

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <!-- Does this bundle track, as Apple defines tracking? -->
  <key>NSPrivacyTracking</key>
  <false/>

  <!-- Domains blocked unless ATT permission is granted -->
  <key>NSPrivacyTrackingDomains</key>
  <array/>

  <key>NSPrivacyCollectedDataTypes</key>
  <array>
    <dict>
      <key>NSPrivacyCollectedDataType</key>
      <string>NSPrivacyCollectedDataTypeDeviceID</string>
      <key>NSPrivacyCollectedDataTypeLinked</key>
      <true/>
      <key>NSPrivacyCollectedDataTypeTracking</key>
      <false/>
      <key>NSPrivacyCollectedDataTypePurposes</key>
      <array>
        <string>NSPrivacyCollectedDataTypePurposeAnalytics</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>

The four top-level keys and what each one drives.
Key	Type	What it affects
`NSPrivacyTracking`	Boolean	Whether the bundle tracks under Apple's definition. Drives the ATT requirement
`NSPrivacyTrackingDomains`	Array of strings	Enforced at runtime: these hosts are blocked without ATT permission
`NSPrivacyCollectedDataTypes`	Array of dicts	Feeds the App Store privacy labels and the privacy report
`NSPrivacyAccessedAPITypes`	Array of dicts	Required reason API declarations. Missing entries are rejected

Tracking domains are enforced, not declared

Three of the four keys are declarations Apple reads at review time. NSPrivacyTrackingDomains is different: the OS enforces it. If NSPrivacyTracking is true and the user has not granted ATT permission, network requests to any listed domain fail on the device.

This is a real outage mode, not a review note

Over-declaring a domain that also carries non-tracking traffic — your attribution endpoint, your CDN — means that traffic dies for every user who declined the ATT prompt, which is most of them. Split tracking traffic onto its own host before listing it, and never list a domain that serves link resolution or content.

How the tracking keys interact.
`NSPrivacyTracking`	`NSPrivacyTrackingDomains`	Result
`false`	Empty	No ATT requirement; no domain blocking
`false`	Non-empty	Inconsistent — Apple flags this at review
`true`	Empty	Declares tracking with no enforced domains; expect questions
`true`	Listed	Listed hosts blocked unless ATT is granted

Tracking, in Apple's sense, means linking data from your app with data from other companies' apps or websites, or sharing it with a data broker. Attribution done with a first-party install referrer or your own click IDs is not tracking; joining your data to a third party's identity graph is.

The SDK signature requirement

Alongside manifests, Apple published a list of commonly-used SDKs — attribution, analytics, ads and crash reporting libraries among them — which must ship a privacy manifest and be signed by their author. If you depend on one, the requirement lands on you at submission.

Common App Store rejection codes for manifest problems.
Code	Cause	Fix
`ITMS-91053`	A required-reason API is used with no declared reason	Add the category and an approved reason code
`ITMS-91061`	A listed SDK is present but not signed	Update to a version the vendor signs
`ITMS-91054`	An invalid reason code for the declared category	Use a code that exists for that category
`ITMS-91055`	A reason code that does not match actual use	Declare the reason that describes what the code does
`ITMS-91056`	Invalid manifest structure or an unknown key	Validate the plist; check for typos in key names

Audit what your dependencies actually declare

# Every manifest inside a built app, including SDK bundles
find Shop.app -name "PrivacyInfo.xcprivacy"

# Read one
plutil -p Shop.app/Frameworks/SomeSDK.framework/PrivacyInfo.xcprivacy

# Is a binary signed, and by whom
codesign -dv --verbose=4 Shop.app/Frameworks/SomeSDK.framework 2>&1 | \
  grep -E "Authority|TeamIdentifier"

# Xcode: Product > Archive, then Generate Privacy Report from
# the Organizer aggregates all of the above into one PDF.

Your manifest does not cover your dependencies

Each bundle declares for itself. An SDK without a manifest does not inherit yours, and its API use still counts against your submission — which is why an app rejected for ITMS-91053 is often using none of the flagged APIs in its own code. Update the dependency; do not declare on its behalf.

Writing one for an app that does attribution

Archive the app and generate the privacy report — it lists every manifest found and every gap.
For each dependency without a manifest, check for a newer version; if there is none, that dependency is a submission risk.
Declare only the data types you genuinely collect. Over-declaring lands in your public App Store privacy labels permanently.
Set NSPrivacyTracking honestly. If you do not join data with other companies' data, it is false and there is no ATT prompt to justify.
Keep NSPrivacyTrackingDomains minimal and never include a host that also serves content, links or configuration.
Add an NSPrivacyAccessedAPITypes entry for every required-reason category your own code touches — UserDefaults is the one almost every app needs.

Apple maintains the authoritative list of categories, reason codes and covered SDKs in its developer documentation under "Privacy manifest files"; verify against it before a submission, because the list has been extended more than once since launch.

iOS SDK documentation

Our iOS SDK documentation covers what the SDK declares in its own manifest, what it does and does not collect, and how attribution works without joining your data to anyone else's identity graph — which is what keeps NSPrivacyTracking false for apps that use it.

Open the ios sdk documentation →

Frequently asked questions

What is a privacy manifest in iOS?: It is a PrivacyInfo.xcprivacy property list inside an app or SDK bundle that declares the data types the bundle collects, whether it tracks users, which domains it uses for tracking, and its reasons for calling APIs Apple designates as requiring a declared reason. Xcode aggregates every manifest in the app and its dependencies into the privacy report submitted with the build.
Does every app need a privacy manifest?: Every app that uses a required-reason API or includes an SDK from Apple's commonly-used list needs one, which in practice is nearly every app that ships with third-party dependencies. Even an app with no dependencies usually reads UserDefaults, which is a required-reason category, so writing a manifest is the safe default rather than an exception.
What is NSPrivacyTrackingDomains, and can it break my app?: It lists the domains a bundle uses for tracking, and unlike the other keys it is enforced on the device: when the bundle declares tracking and the user has not granted App Tracking Transparency permission, requests to those hosts fail. Listing a domain that also serves link resolution, content or configuration takes that functionality down for every user who declined the prompt.
Why was my app rejected with ITMS-91053?: Because the build calls an API in a required-reason category — file timestamps, system boot time, disk space, active keyboards or user defaults — without a matching NSPrivacyAccessedAPITypes entry and approved reason code. The call is frequently inside a dependency rather than your own code, so check the privacy report from the Xcode Organizer to find which bundle is responsible.
Do third-party SDKs need their own privacy manifests?: Yes, and SDKs on Apple's commonly-used list must additionally be cryptographically signed by their author. Manifests do not inherit: yours does not cover a dependency, and a dependency without one leaves a gap that is attributed to your submission. If a vendor has not shipped a manifest and signature, the practical options are updating or replacing the dependency.

Related terms

Required Reason API — A required reason API is an iOS API that Apple has designated as usable only if the calling bundle declares an approved reason for using it in its privacy manifest.
Unattributed installs — An install is unattributed when no signal linking it to a prior ad click or link tap survived the journey through the app store, which can mean the install was organic or that the signal existed and was lost.