Yes, for the SDKs Apple lists. Apple's third-party SDK requirements say a privacy manifest must be included for any listed SDK when you submit a new app or an update that adds it. Signatures also apply when a listed SDK is used as a binary dependency. You remain responsible for all SDK code in your app.
What a privacy manifest is
A privacy manifest is a file that describes the privacy practices of third-party code in one standard format. Apple says Xcode combines the manifests of all third-party SDKs in your app into one report when you prepare to distribute. You can use that report to build more accurate Privacy Nutrition Labels.
The point is practical. Before manifests, you had to read each SDK's documentation and guess. Now the SDK author states what it collects and which sensitive system APIs it uses, and Xcode does the merge.
What Apple's page says about scope
The requirement is tied to a list of named SDKs. The list includes well-known networking, image, analytics, crash reporting, push notification and cross-platform framework packages, and it also covers SDKs that repackage a listed SDK. Any version of a listed SDK is covered.
Two details matter:
- The manifest requirement applies when you submit a new app that includes the SDK, or an update that adds it.
- The signature requirement applies when the listed SDK is used as a binary dependency. When you adopt a new SDK version, Xcode validates that it was signed by the same developer.
The page does not state an effective date. Apple points to its Upcoming Requirements page for timing, so check that page before a release rather than relying on a blog post, including this one.
Which tool answers "do I ship any listed SDK?"
You need an inventory first. A dependency inventory built from your lockfile or resolved package file tells you which SDKs are in the build, including those pulled in transitively. Compare it to Apple's list. If you ship a wrapper from a cross-platform framework, check the underlying iOS packages too, because the list names several plugin packages from those ecosystems.
| Question | Where to look |
|---|---|
| Which SDKs are in the build? | Your lockfile or resolved packages file, or an SBOM |
| Is a listed SDK among them? | Apple's third-party SDK requirements page |
| Does the SDK version include a manifest? | The SDK's release notes or its package contents |
| What will my labels say? | The report Xcode generates when you archive |
Steps for a release
- Generate or export your dependency list for the release build.
- Compare it with Apple's list of SDKs.
- Update any listed SDK that lacks a manifest, or ask its maintainer.
- Archive the app and review the privacy report Xcode produces.
- Make sure your Privacy Nutrition Labels match the report.
What a manifest does not do
A manifest is a declaration, not a test. It does not prove an SDK is free of vulnerabilities, and it does not replace your own review of what the SDK sends off the device. Apple states you must understand the data collection and use practices of the code you include.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and notice how transitive packages appear beside the ones you added by hand. Those are the ones people forget when comparing against a list.
Quick check
Does my app need a manifest for its own code?
Apple's SDK page covers third-party SDKs. For your own app's privacy declarations, check Apple's current developer documentation on privacy manifests.
Does a privacy manifest mean the SDK is secure?
No. It describes data practices. Vulnerabilities are a separate question answered by matching your inventory against advisories.
Safeguard handles the dependency and SBOM side of this, listing what is in a build and matching it against known vulnerabilities. It does not analyze compiled mobile binaries. You can run a free scan on a project.
Sources
Last reviewed: 19 October 2026.
