Inside the iOS privacy manifest is a section that has real runtime teeth: tracking domains. If your app declares that it does tracking, you list the domains involved, and iOS will block connections to those domains when the user has not granted App Tracking Transparency permission. That makes getting the tracking-domain declaration right both a compliance and a functionality matter, since a misdeclaration can break connections or misrepresent your data practices. The domains often come from your SDKs, not just your own code. Here is what tracking domains in the privacy manifest are, how the blocking works, and how to declare them correctly.
Short answer
The iOS privacy manifest, PrivacyInfo.xcprivacy, includes a tracking flag and a list of tracking domains, the domains your app connects to that are used for tracking. Per Apple's documentation, when your app declares that it tracks, iOS blocks connections to the listed tracking domains if the user has not granted App Tracking Transparency permission. So you must list the domains your app or its SDKs use for tracking, and those connections will only succeed when the user consents to tracking. The domains frequently come from third-party SDKs, which provide their own, so build your app's list from your code and your dependencies, and keep it accurate.
What you should know
- The manifest lists tracking domains: domains used for tracking.
- iOS enforces it at runtime: it blocks tracking domains without ATT consent.
- Tracking needs the ATT permission: connections to those domains depend on it.
- SDKs contribute tracking domains: gather theirs into your manifest.
- Accuracy matters both ways: misdeclaring breaks connections or misstates practices.
What are tracking domains in the privacy manifest?
They are the domains your app contacts that are involved in tracking, declared in the privacy manifest. The manifest has a flag indicating whether your app uses data for tracking, and when that is set, a list of the tracking domains, the internet domains that receive or combine data for tracking purposes, typically belonging to ad, attribution, or analytics services. Tracking here has the App Tracking Transparency meaning: linking user or device data with data from other companies for advertising or sharing it with data brokers. So the tracking-domains section is where you enumerate the endpoints that do that. It is distinct from the rest of the manifest, the required-reason APIs and collected-data types, because it is tied directly to ATT enforcement and to the network connections your app makes.
How does tracking-domain blocking work?
By gating those connections on ATT consent. The table outlines it.
| Situation | What iOS does |
|---|---|
| Domain listed as tracking, ATT granted | Connection allowed |
| Domain listed as tracking, ATT not granted | Connection blocked |
| Tracking domain not declared | Inaccurate manifest; tracking undisclosed |
| No tracking, no domains listed | Nothing to block |
The key behavior is that iOS blocks connections to your declared tracking domains when the user has not granted App Tracking Transparency permission. That is a runtime enforcement, not just a disclosure: a tracking SDK that would otherwise phone home is prevented from reaching its domain without consent. So declaring a domain as a tracking domain is partly a promise to the system to gate it on consent. Conversely, failing to declare a domain that does tracking misrepresents your data practices, and declaring domains incorrectly can break legitimate, non-tracking connections, so accuracy cuts both ways.
How do you declare tracking domains correctly?
Identify which domains do tracking, including your SDKs', and list them with the tracking flag set. First, determine whether your app does tracking in the ATT sense, through your own code or any SDK, and set the manifest's tracking flag accordingly. Then list the tracking domains: the endpoints that receive or combine data for tracking, which for most apps come from ad, attribution, and analytics SDKs. Those SDKs provide their tracking domains in their own privacy manifests, so gather them into your app's manifest rather than guessing, and include only domains genuinely used for tracking, since listing a non-tracking domain could block a connection your app needs. Pair this with requesting App Tracking Transparency before tracking, and keep your App Privacy disclosures consistent. The goal is a manifest where the tracking flag and domains match what your app and dependencies actually do.
What to watch out for
The first trap is omitting a tracking domain that an SDK uses, which misrepresents your data practices and can draw scrutiny; gather your SDKs' tracking domains. The second is declaring a non-tracking domain as a tracking domain, which can cause iOS to block a connection your app legitimately needs. The third is forgetting that listed tracking domains are blocked without ATT consent, so you must request that permission. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and surfaces the network endpoints and SDKs in your build, which helps you see which domains your app contacts so your tracking-domain list reflects reality. The manifest itself you complete in the project.
What to take away
- The iOS privacy manifest lists tracking domains, the domains your app contacts for tracking, alongside a flag indicating that the app tracks.
- iOS blocks connections to declared tracking domains when the user has not granted App Tracking Transparency permission, so those connections depend on consent.
- List the tracking domains accurately, gathering your SDKs' tracking domains, and avoid declaring non-tracking domains, since misdeclaring breaks connections or misstates practices.
- Use a pre-submission scan such as PTKD.com to see which endpoints and SDKs your app contacts so your tracking-domain declaration reflects reality.
