An Apple privacy manifest is a property list file, named PrivacyInfo.xcprivacy, that sits inside your app or inside a third-party SDK and states what data it collects, whether it tracks users, and why it uses certain sensitive system APIs. Since 1 May 2024, Apple has required new and updated apps to declare approved reasons for those APIs. If your app or any SDK inside it falls short, App Store Connect warns you or the build is rejected. This guide explains what goes in the file, where teams go wrong, and what UK businesses should do beyond Apple's rules.
TL;DR
- A privacy manifest is a
PrivacyInfo.xcprivacyfile that declares data collection, tracking domains and required reason API usage for your app and each SDK it contains. - You are responsible for every line of code in your app, including third-party SDKs, so audit dependencies before you add them, not on submission day.
- Using a required reason API without an approved reason in the manifest leads to a missing API declaration error (ITMS-91053) and a rejected upload.
- The manifest is a living file: update it whenever you add or upgrade an SDK, and check the data flows with a network monitor.
- In the UK, Apple's rules sit alongside PECR and UK GDPR, so a manifest that passes review does not by itself make you compliant.
Table of Contents
- What a privacy manifest is and why Apple introduced it
- What goes inside PrivacyInfo.xcprivacy
- Required reason APIs: the part that blocks releases
- Third-party SDKs: you own what you ship
- A practical process to get your manifest right
- What UK businesses need beyond Apple's rules
- Common mistakes we see
- Our view on privacy manifests
- Getting help with your app's privacy and App Store readiness
- FAQ
- Sources
What a privacy manifest is and why Apple introduced it
The manifest is a machine-readable statement of privacy behaviour. Apple introduced it at WWDC23 as a tool to help you accurately identify the privacy practices of your app's dependencies, and to let SDK authors share those practices in a standard format.
The reason is simple. Third-party SDKs add useful features, but they can also affect user privacy in ways that are not obvious to the developer. Apple's own announcement says as much. Before manifests, an app team often had no reliable way to know what a bundled analytics or advertising library did with data.
The manifest also feeds the privacy "nutrition labels" shown on each App Store product page. When Xcode prepares your app for distribution, it can combine the manifests from all your SDKs into one report, which makes the label far easier to fill in accurately. You can read more about how the App Store presents privacy information on Apple's site.
It is not only a compliance checkbox. Apple's framing is transparency and user control, and developers who adopt the practice early tend to meet fewer hurdles in App Review, according to Apple's February 2024 update.
What goes inside PrivacyInfo.xcprivacy
The file is a property list you add to your target's resources in Xcode, as set out in Apple's guidance on adding a privacy manifest. It records four things:
| Section | What you declare | Typical example |
|---|---|---|
| Tracking | Whether the app or SDK uses data for tracking, as Apple defines it under App Tracking Transparency | An advertising SDK that links data to other companies' data |
| Tracking domains | The internet domains used for tracking | An ad network endpoint |
| Collected data types | Each type of data collected, whether it is linked to the user, whether it is used for tracking, and the purpose | Email address for account management |
| Required reason APIs | Each category of sensitive API used, with an approved reason code | User defaults used to store app settings |
The tracking and data type sections should match your App Store privacy label and what your privacy notice tells users. If one of the three says something different from the others, that is the first thing a regulator, a journalist or a reviewer will notice.
Required reason APIs: the part that blocks releases
Most rejected builds fail on required reason APIs. These are system APIs that Apple considers open to misuse for device fingerprinting. If your app or an SDK calls one, you must pick an approved reason from Apple's published list in the manifest. Apple's documentation on describing use of required reason API holds the current categories and reason codes, so check it each release rather than relying on a blog post, including this one.
The categories cover areas such as file timestamps, system boot time, available disk space, active keyboards and user defaults. The last one catches many teams out, because almost every app reads or writes user defaults somewhere.
Two rules matter in practice:
- Use an approved reason only if it truly describes your use. If none of the listed reasons fits, you cannot invent one. You need to find another technical approach.
- Fingerprinting is prohibited whatever the user consents to. Asking permission for tracking does not make device fingerprinting acceptable.
When you upload a build that references one of these APIs without a declared reason, you receive the email and error known as ITMS-91053, missing API declaration. The fix is to add or correct the manifest and upload again, but each failed round costs days when a launch date is fixed.
Third-party SDKs: you own what you ship
Apple states plainly that developers are responsible for all of the code in their apps, including frameworks and libraries from other sources. A widely used SDK does not carry the burden for you.
For commonly used SDKs, Apple asks for their own privacy manifests and signatures. In practice that means three habits:
- Keep an SDK register. List every library, its version, its purpose and the data it touches. Include transitive dependencies, since a package you chose may pull in others.
- Check each SDK's manifest before you adopt it. If a vendor has not published one, ask why, or choose another library.
- Rebuild the manifest on every upgrade. Updating an SDK can add new API usage, and the combined report in Xcode will show you what changed.
Cross-platform frameworks need the same care. Apps built with React Native, Flutter, Unity or Kotlin Multiplatform still ship an iOS binary, and the framework's own code may call required reason APIs. The Kotlin Multiplatform documentation, for example, notes that the issue can affect any Apple ecosystem app, native or multiplatform. Check your framework's current guidance and plugin versions before submitting.
A practical process to get your manifest right
Here is the sequence we would follow on a project, whether it is new or a long-running app.
1. Inventory your code and dependencies
List the SDKs, Swift packages, CocoaPods and binary frameworks in the build. Note which ones do analytics, advertising, crash reporting, payments, maps or authentication. These are the most likely to collect identifiers.
2. Create the manifest and declare required reason APIs
In Xcode, add an App Privacy file to the app target. Search your own code and your SDK list for the required reason categories, then select the approved reason that matches each real use. Fewer declarations is not better. Accuracy is.
3. Verify with real network traffic
A manifest describes what you believe happens. Test that belief. Use a network inspection tool on a test device, run through key journeys such as first launch, sign-up and checkout, and see which domains the app contacts and what leaves the device. Many advertising and analytics tools routinely collect identifiers such as IP addresses and advertising IDs, which the ICO treats as personal data when combined with other information. Do this both before and after you build the manifest.
4. Generate the privacy report and reconcile your labels
Archive the app, then generate the privacy report in Xcode. Compare it with your App Store privacy label and your privacy notice. They should say the same thing.
5. Build a re-check into every release
Put a manifest check in your release checklist: new SDK, SDK upgrade, new Apple API list, new feature that reads device data. Treat it like a security review, not a one-off task.
What UK businesses need beyond Apple's rules
Passing App Review shows that your declarations are internally consistent for Apple. It does not show that you comply with UK law.
In the UK, the ICO's guidance on how to comply with the PECR rules says you must consider storage and access technologies as part of the design of your service, and have appropriate arrangements with any third parties you use. In practice, you need to identify each technology that stores or reads information on the user's device, then show that it either falls under an exemption or has valid consent behind it.
The ICO has shown it will act where data flows to advertising partners are poorly controlled. Its reprimand of Grindr cited, among other things, the restriction of data flows to advertising partners and the need for a full list of the parties involved. If your app handles health, sexuality, religion or other special category data, the stakes are higher still. Take advice from a data protection specialist or your DPO on what applies to you.
The manifest can support that work. A maintained SDK register, verified data flows and a consistent privacy label are exactly the evidence you want if anyone asks questions. If you need extra engineering capacity to run these audits alongside feature work, nearshore developer hiring and staff augmentation is one way to add hands without slowing the roadmap.
For wider context, we have written about data privacy best practices for mobile app developers, safeguarding user trust and the role of privacy in apps.
Common mistakes we see
- Treating the file as set and forget. The manifest must change when your SDKs change.
- Assuming SDKs only touch functional data. Analytics and advertising tools often collect identifiers you did not ask for.
- Copying reason codes from a forum post. A reason code that does not describe your real use is a compliance problem, even if the build passes.
- Leaving it to the final week. Auditing dependencies when you add them is far cheaper than discovering gaps at submission.
- Mismatch between manifest, label and privacy notice. Users, reviewers and regulators compare them.
- Forgetting web views and embedded content. Third-party content loaded inside the app can still send data, so include it in your traffic checks.
Our view on privacy manifests
We have shipped more than 300 apps, and the pattern is consistent: privacy problems are rarely a single dramatic decision. They build up through small choices, such as an SDK added for a quick campaign, or an analytics library nobody revisited after the first release.
That is why we treat the manifest as a design input, not a submission chore. In our Discover phase we ask what data the app really needs, and which third-party tools earn their place. Often the best privacy decision is to leave an SDK out. We also take a technology-agnostic approach, so we recommend the platform that suits the project, and we weigh how that choice affects dependencies and long-term maintenance.
For charities, retailers and healthcare organisations, user trust is part of the product. A clean manifest, an accurate privacy label and a plain-English notice all say the same thing: we know what our app does. Teams that build this in from the start tend to get through review with fewer surprises, and they spend less time on rework close to launch.
— Paul
Getting help with your app's privacy and App Store readiness
If you already have an app in the store and are not sure its manifest is complete, our Mobile App Clinics are a practical place to start. If you are planning a new build, our Discover, Design, Develop and Deploy process puts these decisions in front of you before they become submission problems. To talk through a project, get in touch about a business app. You can also read our guide to mobile app security best practices for UK businesses.
FAQ
Is a privacy manifest mandatory for every iOS app?
Apple requires apps that use required reason APIs to declare approved reasons, and expects privacy manifests and signatures for commonly used third-party SDKs. The requirement became enforceable for new and updated apps on 1 May 2024. Even if your app seems simple, an SDK inside it may trigger the requirement, so check rather than assume.
What is the file called and where does it go?
It is called PrivacyInfo.xcprivacy. You add it to the resources of your app target, or to the SDK target if you build a library. Xcode's App Privacy template creates the structure for you.
What happens if I use a required reason API without declaring a reason?
Apple sends a missing API declaration notice (ITMS-91053), and the upload can be rejected. You need to add an approved reason that truthfully matches your use. If no approved reason fits, you must change how the feature works.
Does a privacy manifest make my app UK GDPR or PECR compliant?
No. The manifest is an Apple platform requirement. UK law has its own rules on storage and access technologies, consent and personal data, and the ICO's PECR guidance is the place to start. Speak to a data protection professional about your specific app.
How often should I update the manifest?
Every time you add or upgrade an SDK, change the data your app collects, or Apple updates its required reason API list. Add it to your release checklist so it happens by default.
Sources
- Reminder: Privacy requirement for app submissions starts May 1, Apple Developer
- Get started with privacy manifests, WWDC23, Apple Developer
- Privacy updates for App Store submissions, December 2023, Apple Developer
- Privacy updates for App Store submissions, February 2024, Apple Developer
- User Privacy and Data Use, Apple Developer
- Adding a privacy manifest to your app or third-party SDK, Apple Developer Documentation
- Describing use of required reason API, Apple Developer Documentation
- ITMS-91053: Missing API declaration
- How do we comply with the PECR rules?, ICO
- ICO reprimand of Grindr