Your privacy manifest and your privacy policy are two different documents—and they should agree.

GENERAL INFORMATION · JULY 2026

Two files, one set of facts

Most teams meet the privacy manifest as a build problem. A dependency updates, App Store Connect returns a notice, someone adds a file called PrivacyInfo.xcprivacy, and the submission goes through. The file then sits in the repository, and nobody reads it again.

That is a missed opportunity, because the manifest is one of the few places where a team is made to write down, in a fixed vocabulary, what its app actually touches. Your privacy policy is trying to describe the same thing in prose. When the two disagree, one of them is wrong about your own product—and the disagreement is legible to anyone who looks at both.

What the manifest is

Apple documents the privacy manifest as a file named PrivacyInfo.xcprivacy that describes the data an app or a third-party SDK collects and the required-reason APIs it uses. Apple’s documentation organizes it around four top-level keys: NSPrivacyTracking, NSPrivacyTrackingDomains, NSPrivacyCollectedDataTypes, and NSPrivacyAccessedAPITypes.

Each collected-data entry is described with a small set of keys—the data type, whether it is linked to the user, whether it is used for tracking, and the purposes it serves. The permitted values are enumerated by Apple: at our retrieval on July 25, 2026, Apple’s reference pages listed 35 collected-data-type values and 6 purpose values (ThirdPartyAdvertising, DeveloperAdvertising, Analytics, ProductPersonalization, AppFunctionality, Other, each prefixed NSPrivacyCollectedDataTypePurpose).

Separately, Apple documents a set of required-reason APIs—at retrieval, five categories, each with its own approved reason codes—which an app must declare a reason for using. Apple’s own page states that it updates that list from time to time, so read it at the source when you are filling the file in, not from anyone’s summary, including this one.

Apple’s required-reason page also states that, from May 1, 2024, apps that do not describe their use of required reason API in their privacy manifest are not accepted by App Store Connect.

Read the current requirements directly from the publisher: Privacy manifest files, Describing data use in privacy manifests, and Describing use of required reason API.

Where the two documents drift apart

• The SDK declared something you never wrote down. A vendor ships its own manifest. Its declared data types become part of your app’s privacy story, and your policy may never mention that vendor or that category.
• A purpose appears in one document only. The manifest says a data type serves ThirdPartyAdvertising; the policy describes analytics and says nothing about advertising.
• Tracking is declared inconsistently. NSPrivacyTracking and the tracking flag on a data type say one thing; the policy’s sharing section, the App Privacy answers, or the absence of a tracking-permission prompt say another.
• The policy is broader than the app. A generic policy claims categories the manifest does not declare and the app never collects. Over-disclosure is its own inaccuracy.
• A feature shipped and neither file moved. Both documents describe the app as it was two releases ago.

A practical reconciliation pass

1. Open PrivacyInfo.xcprivacy and list every declared data type, its linked flag, its tracking flag, and its purposes.
2. Do the same for every third-party SDK manifest your build pulls in.
3. Put that list beside your privacy policy’s collection, purpose, sharing, and retention sections.
4. Mark every row that appears in one document and not the other—in either direction.
5. Put the App Store Connect App Privacy answers beside both, and mark the same way.
6. For each mismatch, decide which document is wrong about the product. That is the real question, and it is usually answerable by the team.

What you are left with is a short list of genuine discrepancies rather than a vague worry.

Why this is a legal-adjacent problem, not only a build problem

The manifest is a technical artifact, but it is also a statement about your product. Your privacy policy is a public representation to your users. Your App Privacy answers are representations to the platform. When those disagree, the interesting question is not which file to edit—it is which statement about your product is accurate, and what has been represented to whom.

The useful last check

Could someone read your manifest and your privacy policy together and come away with the same understanding of what your app does with information? If the two require different mental models of the same product, the gap is real, and it is better found by you than by anyone else.

Apple’s requirements change. The counts and dates on this page reflect Apple’s own pages as read on July 25, 2026; read the linked Apple documentation for the current requirement.

If you would like both documents read

The Focused Review is a written review of your app’s existing, final-form Privacy Policy and Terms of Use — $275 flat, one app, both documents, under Tennessee law. You receive written issue spots and considerations. It is not drafting, not revisions, not a compliance certification, and it does not produce or edit code or manifest files.

Have both final documents? Begin the private Focused Review →