Apple's required-manifest SDKs, mapped to npm packages

Why this did not already exist

Apple's list is authoritative and framework-agnostic: 86 SDK names, no context. It is a correct answer to a question React Native developers are not asking, because they do not think in pod names. They think in package.json.

The translation layer between the two is the whole difficulty, and it is why an ITMS-91061 email is so frustrating — it can name GTMSessionFetcher, which you have never heard of, installed by GoogleSignIn, which was installed by a login button you added eight months ago.

Everything below is that translation.

How to use it in thirty seconds

# 1. What do you actually ship?
grep -oE '"(@?[a-z0-9@/._-]+)": "' package.json | tr -d '":' | sort

# 2. What already carries a manifest?
find node_modules -name "PrivacyInfo.xcprivacy" | sed 's|node_modules/||' | cut -d/ -f1 | sort -u

# 3. What resolved into the iOS build, transitives included?
grep -E '^\s+- ' ios/Podfile.lock | sed 's/[ -]*//' | cut -d' ' -f1 | sort -u

Step 3 is the important one. Podfile.lock is the ground truth, because it contains what was actually resolved rather than what you asked for. Intersect it with the tables below.

The direct dependencies (18)

These arrive because you installed them. If one of these is in your package.json, the SDK is in your app.

The transitive ones (32) — where the rejections come from

You did not install any of these. They arrived under something else, and they are the usual cause of an ITMS-91061 that names a framework you have never heard of.

Flutter-only entries (20)

On Apple's list, but they reach an iOS binary through Flutter rather than React Native. Listed for completeness — if you are not embedding Flutter, ignore them.

On Apple's list, no common RN route (16)

These are on Apple's list and can appear in an RN app through a bespoke or less common native module, but there is no widely-used npm package that reliably pulls them in. If one of these turns up in your build, look at your least-common native dependency.

The four fixes, in order of preference

1. Update the package. Most maintained libraries added PrivacyInfo.xcprivacy during 2024. Check the changelog for "privacy manifest" and bump.

2. Update the transitive pod, not the wrapper. If nanopb is the problem, bumping @react-native-firebase/app may not move it. Check Podfile.lock for the resolved version and pin the pod explicitly in the Podfile if you have to.

3. Replace the package. For an abandoned library this is the only real answer. A package that will never ship a manifest is now a shipping blocker rather than technical debt.

4. Remove it. Frequently the fastest. A charting library used on one screen, a keyboard manager from 2022, an analytics SDK nobody reads — each removal deletes a whole class of rejection.

What does not work: adding entries for someone else's framework to your app's PrivacyInfo.xcprivacy. Apple's requirement is per-bundle, and states a third-party SDK "can't rely on the privacy manifest files for apps that link the third-party SDK." It will upload and fail identically.

Caveats, stated plainly

Apple's list changes. It is transcribed here on 6 September 2026 and Apple updates it. The date is on this page and in the JSON for that reason.

The npm mapping is compiled by us, not by Apple. Apple publishes the SDK names; the routes into React Native projects are our work, drawn from how these packages resolve in practice. Verify against your own Podfile.lock. It is the only source that knows what your build actually contains.

Package internals change between versions. A library that vendored a listed SDK last year may not now, and vice versa.

Absence from these tables is not safety. Sixteen entries are on Apple's list with no common RN route, and a bespoke native module can pull in any of them.

Reuse it

The JSON is CC BY 4.0. Use it in your own tooling, your own CI check, your own article — attribute it to shipcheck.bakerventuresstudio.com and keep the transcription date attached, because a stale copy of this data is worse than none.

If you find a wrong or missing mapping, that is genuinely useful to know — the whole point of publishing it as data is that it can be corrected.

What shipcheck does with it

shipcheck runs this intersection automatically: it reads package.json, Podfile.lock, node_modules and every PrivacyInfo.xcprivacy in the tree, and reports which listed SDK is missing a manifest — before you build, inside the Claude Code session you already have open, with nothing uploaded anywhere.

ITMS-91061 in detail. · ITMS-91053 in detail. · Every required-reason category and code.

Questions and answers