Apple names the SDKs that need a privacy manifest, and the list runs to 86 entries.
There is one list, it sits on Apple's Third-party SDK requirements support page, and when it was read on 21 October 2026 it held 86 entries. If your app contains one of them, your upload to App Store Connect has to carry that SDK's privacy manifest, and where the SDK came in as a binary dependency it has to carry a signature too. The part people get wrong is not the list. It is who is supposed to write the file. The vendor authors it. You ship it. You are the one who gets the rejection email. Most people meet this on their first attempt at publishing to the App Store.
What follows is the list itself, where the duty actually sits, what the rejection looks like and what you can do about it, and where the file belongs in each kind of product. Every figure and date below comes from Apple's own pages, read on 21 October 2026.
See the listThe short version
You cannot write this file for somebody else's binary. Your lever is the version number.
A privacy manifest is a property list called PrivacyInfo.xcprivacy. It sits inside a bundle, and it records two things: the data types that bundle collects, and the required reason APIs it touches. Required reason APIs are the ones Apple has flagged as useful for fingerprinting a device, so it makes you state a reason before you read them. An app has one manifest. Each SDK that needs one has its own.
That last sentence is the whole problem. Apple is explicit that an SDK cannot lean on your app's manifest to declare its own required reason API use, and equally explicit that your app's manifest does not have to cover what an SDK collects. So when a listed dependency turns up without a valid manifest, the fix is not something you can edit. It is a version bump, or a mail to the vendor, or dropping the dependency. Find that out in week one, not on submission day.
Which SDKs does Apple require a privacy manifest and a signature for?
The ones on a single page, under the heading SDKs that require a privacy manifest and signature. Apple describes them as commonly used SDKs in apps on the App Store. Read on 21 October 2026, that heading was followed by 86 entries, in alphabetical order, Abseil at the top and webview_flutter_wkwebview at the bottom. Twelve of them begin with Firebase. Six begin with FBSDK or FBAEM. Four are OneSignal components. Others are low level network and serialisation code that nobody adds on purpose, such as BoringSSL and nanopb.
Read the names and you notice the list is built from build artefacts, not from products. There is no entry called Firebase, and none called Firebase Analytics. There are twelve separate Firebase components, plus GoogleUtilities, GoogleDataTransport and GoogleToolboxForMac. Those are names that show up in a lock file rather than in anything you typed. So check the resolved dependencies, not the ones you chose. Apple closes that gap from its side too: any version of a listed entry is covered, and so is any SDK that repackages one of them.
The cross-platform names are the ones worth stopping on. Flutter, Capacitor, Cordova and UnityFramework are all listed, and so is hermes. React Native's own documentation, last updated 12 August 2026, says Hermes is the engine React Native uses by default and needs no configuration to enable. So a React Native app that nobody has customised is already shipping a listed component. The same goes for a Flutter app, several times over, because a long run of its plugin pods appear by name: url_launcher, path_provider, share_plus, sqflite and more.
Two cautions about the page, as opposed to the list on it. It carries no last-updated stamp, only a copyright line, so you cannot see when an entry arrived. And it still holds the shape of an announcement: Apple's developer documentation links to it as Upcoming third-party SDK requirements even though the page title has dropped the word and the deadline behind it passed in February 2025. Treat it as the current rule, re-read it before each release, and keep a note of what it said last time.
Check yours
Is your dependency on the list?
All 86 entries, in Apple's order, as the page read on 21 October 2026. Type a pod, package or framework name. Search your lock file, not your Podfile, because most of these arrive as something else's dependency.
86 of 86 shown.
Any version of a listed entry counts, and so does anything that repackages one.
Does the requirement fall on you or on the SDK vendor?
On both, and Apple writes it down twice, once for each audience. Its Privacy manifest files documentation addresses the SDK author: you need to include a manifest in your third-party SDK if it is on that list. Its Third-party SDK requirements page addresses you: you must include the manifest for a listed SDK when you submit a new app that contains it, or an update that adds it. One file, two duties. Authoring is the vendor's. Shipping, and the consequence of not shipping, is yours.
Apple does not leave the division to inference either. Its Describing data use in privacy manifests page says third-party SDKs need to provide their own manifests for the data they collect, and that your app's manifest does not need to cover it. Its Describing use of required reason API page goes further: an SDK cannot rely on the manifest of the app that links it, nor on another SDK's manifest, to report its own required reason API use. Every executable and dynamic library that touches one of those APIs needs the declaration in its own bundle. There is no delegating upward.
One documented exception to that tidy model comes from Expo rather than Apple, and it matters if you build with CocoaPods. Expo's privacy manifests guide, modified 29 July 2026, says Apple does not correctly parse every PrivacyInfo file bundled by a static CocoaPods dependency, and that you may have to repeat those required reasons in your own app's manifest or in app config. Expo also points out that every Expo SDK package using a required reason API carries its own file in the package directory, so you can read the values out of node_modules rather than guessing them.
The practical reading of all this is a sourcing rule, not a coding rule. Before you add a dependency, check whether it is on the list, and if it is, check that the version you are pinning ships PrivacyInfo.xcprivacy. Apple states plainly that when you use a third-party SDK you are responsible for all the code it puts in your app, and that you need to know its data collection practices. That is the same posture the rest of the store rules take. It is why the google play data safety form makes you answer for library behaviour you never wrote, and why the account deletion requirement lands on you even when a vendor holds the data.
What happens when App Store Connect finds an invalid manifest?
The submission is rejected and you get an email that names the file and its path inside your app bundle. This is not a review decision and no human looks at it. It happens at upload, which is why it catches people who have rehearsed everything else. The error string is ITMS-91056, invalid privacy manifest, followed by the path. Apple's technote TN3181, first published 12 November 2024, prints that message and lists the key by key reasons a file comes back invalid.
Two dates sit behind all of this, and both are in the past. From 1 May 2024, by Apple's own wording, apps that do not describe their required reason API use in a privacy manifest are not accepted by App Store Connect. From 12 February 2025, apps submitted for review must contain a valid privacy manifest for a set number of commonly used third-party SDKs. Apple's documentation still prints both sentences in the future tense, read on 21 October 2026, which is the main reason people still treat this as a thing that is coming.
When the bad file belongs to a vendor, Apple's first instruction is to ask them for a version with a valid manifest. When that is not available and you have to ship, the documentation gives two fallbacks and a warning. You can find the invalid manifest inside your app archive, delete it, and submit the archive from Xcode. Or you can fix the validation errors in the file yourself and submit. Either edit breaks the archive's signature, and Xcode re-signs the app when you distribute it from the Archives organiser.
Catch it earlier than the email. Running plutil with the -lint option against PrivacyInfo.xcprivacy tells you whether the file is a well-formed property list, and Apple is careful to add that a valid property list can still be an invalid manifest if its keys and values are not the ones App Store Connect expects. A TestFlight upload is the cheap rehearsal: the check runs at upload, so you find out without spending a review cycle.
Apple, Adding a privacy manifest to your app or third-party SDK, read 21 October 2026
Where does the file go, and what goes in it?
The name is fixed. PrivacyInfo.xcprivacy, no variations. For an iOS, iPadOS, tvOS, visionOS or watchOS app it sits at the root of the app bundle. For macOS and Mac Catalyst it goes in Contents/Resources. For a framework it is the root of the framework bundle on the mobile platforms, and Versions/A/Resources on macOS and Mac Catalyst. Xcode puts it in the right place when you add it to the target that builds your product, through File, then New File, then App Privacy File in the Resource section.
Two packaging cases bite. A Swift package can carry a manifest in the target's source folder or a Resources subfolder, but Xcode does not treat privacy manifests as resources on its own, so you declare the file explicitly in Package.swift, with process on either the file or the directory holding it. And a plain static library, the .a archive, cannot carry resources at all. Apple's instruction there is to build a static framework target instead. Xcode 15 and later can bundle resources in a static framework, so the manifest goes into that target's bundle resources.
Inside the file there are four top level keys. NSPrivacyTracking, a boolean for whether the code uses data for tracking as App Tracking Transparency defines it. NSPrivacyTrackingDomains, the domains the code talks to that engage in tracking, which only applies when the first key is true. NSPrivacyCollectedDataTypes, the data types collected, with whether each is linked to the person and whether it is used to track. And NSPrivacyAccessedAPITypes, one dictionary per category of required reason API, each with the approved reasons you are claiming. The tracking keys interact with the runtime, so get them straight before you tune your push notification permission prompt and the rest of your consent flow.
The payoff for getting all of this right is a document you can read. Choose Product, then Archive, then control-click the archive in the Xcode Organiser and choose Generate Privacy Report. Xcode aggregates your manifest and every manifest from the SDKs you link into one report, laid out like the App Store privacy section. It is the fastest honest answer to the question of what your dependencies collect, and the right thing to have open when you fill in App Privacy in App Store Connect.
The manifest and the signature are two different requirements
They arrive in the same sentence on Apple's page and get treated as one rule. They are not. One is a declaration checked at upload. The other is a supply chain check run by Xcode, and it only attaches where the listed SDK comes in as a binary.
| The question | Privacy manifest | SDK signature | Same answer for both |
|---|---|---|---|
| What it is | A property list named PrivacyInfo.xcprivacy, inside the bundle | A code signature made by the SDK's own developer | No |
| Required for an SDK on Apple's list | Yes | Only where that SDK arrives as a binary dependency | No |
| Required for an SDK that is not listed | Only if it uses a required reason API, collects data, or contacts a tracking domain | Not required, and Apple encourages it rather than demanding it | No |
| Who has to produce it | The SDK's own developer | The SDK's own developer | Yes |
| Where the failure shows up | App Store Connect, at upload, then an email naming the file path | Xcode, when you move the app to a new version of the SDK | No |
| Who has to deal with it | You, the app developer | You, the app developer | Yes |
Where this lands if a builder generated your app
It lands on you, in the same place it lands on everyone else, and with one detail that catches generated projects specifically. Newly is an AI app builder: you describe an app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync, so the dependency list is yours to read. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not submit to the App Store for you, because Apple requires the owner of the content to submit. It costs from $25 a month and there is no free tier.
The detail is hermes. A React Native project uses Hermes by default, Hermes is on Apple's list, and nobody chose it in a prompt. So the honest expectation for any generated React Native app is that it has at least one listed dependency from the first build, before you have added analytics or push or anything else. There is nothing wrong with the generated code. That is simply what the stack contains, and it is why the right time to read the list is while you are still picking libraries.
The rest is ordinary release hygiene, and a TestFlight upload is where you learn it. Keep a note of the version of every listed dependency you ship. Before you add a library, search the list for it. When you move to a new version, generate the privacy report and read it rather than assuming nothing moved. None of this needs a tool. It needs the habit of treating other people's code as code you are answerable for, which is what Apple says it is.
Questions people ask about third-party SDK privacy manifests
Apple publishes one list, under the heading SDKs that require a privacy manifest and signature, on its Third-party SDK requirements support page. Read on 21 October 2026 it held 86 entries, from Abseil to webview_flutter_wkwebview. Twelve of them begin with Firebase. Six begin with FBSDK or FBAEM. Four are OneSignal components. Flutter, Capacitor, Cordova, UnityFramework and hermes are all named, so the list reaches well past native Swift projects. Apple adds that any version of a listed entry is covered, and so is any SDK that repackages one.
Check the list while you are still choosing libraries
Every name on it is cheap to avoid in week one and expensive to remove in week nine. Build the app, read your lock file against the list, and put a TestFlight upload in front of your first real submission.
Start building