iOS Privacy Manifests for React Native: what Apple requires and what to check
Apple introduced PrivacyInfo.xcprivacy at WWDC23. Since May 1, 2024, App Store Connect requires approved reasons for the required-reason APIs your app uses, and a privacy manifest (plus a signature, for binary SDKs) for any SDK on Apple's list of commonly used third-party SDKs that a new app includes or an update adds. Apple encourages other SDKs to adopt manifests but doesn't require it.
React Native added a privacy manifest to its app template in April 2024 and bundles manifests in its own pods from 0.75. Many popular React Native libraries ship no manifest of their own, and most don't need one. What matters is whether a library's native code calls required-reason APIs, and whether your app bundles an SDK on Apple's list, such as Firebase, OneSignal, Lottie, or SDWebImage.
The fix is concrete: check what your app bundles, add missing reasons, and upgrade or replace SDKs that don't meet the requirement. Ignoring it tends to surface as a rejected upload during a release that was supposed to be routine.
You upload a build and App Store Connect sends back an email: a missing API declaration in your app, or a missing privacy manifest for an SDK you added. Either one blocks the release until you fix it.
This post is what privacy manifests are, what React Native handles for you, and the audit you should run before your next App Store submission.
What a privacy manifest actually is
A privacy manifest is a single file: PrivacyInfo.xcprivacy. It's a property list, XML format. It lives inside an app bundle or an SDK bundle.
It exists because Apple wanted three classes of data to be declared explicitly rather than inferred from the code:
- What user data the app or SDK collects, and how it's used
- Whether that data is linked to user identity, and whether it's used for tracking under the App Tracking Transparency framework
- Which "required reason" APIs the code calls, and for what approved reason
The third one is the new compliance trap. Apple has defined a set of API categories — NSFileManager timestamps, UserDefaults, system uptime, disk space, active keyboards, and a few others — that were historically used for device fingerprinting. Since May 1, 2024, App Store Connect doesn't accept new apps or updates that use APIs in those categories without an approved reason in a privacy manifest.
The enforcement timeline
| Date | What changed |
|---|---|
| June 2023 (WWDC23) | Apple introduced privacy manifests, SDK signatures, and required-reason APIs |
| February 29, 2024 | Apple announced the enforcement dates |
| March 13, 2024 | App Store Connect began emailing developers whose uploads use required-reason APIs without declared reasons |
| May 1, 2024 | Uploads need approved reasons for the listed APIs the app's code uses. A new SDK from Apple's list needs its privacy manifest, and a signature when added as a binary dependency |
| February 12, 2025 | The date Apple's ITMS-91061 "Missing privacy manifest" rejection cites for new apps, or updates that add a listed SDK, when that SDK has no manifest |
Apple's list names specific SDKs, and the requirement also covers any SDK that repackages one of them. For everything else, a manifest is encouraged rather than required, but required-reason APIs still need declared reasons wherever the code runs. Apple can change the list, so check the third-party SDK requirements page before a release.
Three things a manifest declares
The privacy manifest has three top-level keys you care about.
NSPrivacyCollectedDataTypes
The data categories your code collects. Each entry lists a data type (email, location, device ID, contacts, etc.), whether it's linked to identity, whether it's used for tracking, and the purposes (analytics, advertising, app functionality, etc.).
This is the section that maps to your App Store privacy nutrition labels. They should match.
NSPrivacyTracking and NSPrivacyTrackingDomains
Whether the app or SDK does cross-app/cross-site tracking under ATT, and the list of domains that participate. This is mostly relevant for analytics and advertising SDKs.
NSPrivacyAccessedAPITypes
The required-reason APIs your code calls, paired with an Apple-approved reason. This is the section that catches React Native developers off guard. You may call UserDefaults without thinking about it; Apple wants you to declare why.
The approved reasons are codes defined in Apple's documentation, for example CA92.1 (user defaults that only your app can read and write) or 1C8F.1 (user defaults shared with apps and extensions in the same App Group). Pick the code that matches what your code actually does.
What React Native handles for you
React Native handled this in stages, all verifiable in the published npm packages:
- April 2024: the app template gained
ios/<App>/PrivacyInfo.xcprivacyin 0.74.0, backported to the 0.71.19, 0.72.14, and 0.73.8 patch releases. It declares the required-reason API categories React Native uses: file timestamps (C617.1),UserDefaults(CA92.1), and system boot time (35F9.1). - Later patches (0.72.15, 0.73.9, 0.74.1) added a CocoaPods script,
privacy_manifest_utils.rb, that collects privacy manifest entries from your pods. - 0.75.0: React Native's own pods and bundled dependencies (React, cxxreact, Folly, glog, boost) ship their own
PrivacyInfo.xcprivacyfiles.
Template changes don't reach existing projects on their own. If your app was created before the template change, check that PrivacyInfo.xcprivacy exists in your app target; the Upgrade Helper diff shows the file to add for your versions.
What's still on you:
- Your app's own code, anywhere you call a required-reason API
- Third-party React Native libraries whose native code calls required-reason APIs
- Native iOS SDKs you embed, directly or through a React Native wrapper, especially any on Apple's list (Firebase, OneSignal, Lottie, SDWebImage, and others)
The third-party library piece is where the audit lives.
Older React Native versions don't include these files, but the app-level manifest is an ordinary file you can add to any project. Declare the reasons for the required-reason APIs your app and React Native actually use, and upgrade when you can: only supported versions get fixes.
How to audit your dependencies
Start with Xcode: archive the app, then in the Organizer use Generate Privacy Report, which combines the privacy manifests of everything bundled in the build. Then walk your CocoaPods install directory to see which pods include a PrivacyInfo.xcprivacy file.
A pod without a manifest isn't automatically a problem. For each one, check:
- Is it on Apple's list, or does it repackage an SDK that is? If so, you need a version that ships the manifest, and a signed build if it's a binary framework.
- Does its native code call required-reason APIs? Grep the source for
UserDefaults, file timestamp APIs,systemUptime, disk space queries, and the other categories. If it calls none, a missing manifest is low urgency. - Is there a newer version with a manifest? Often the library has been updated but you're pinned to an old version.
- Is it maintained? A library without recent releases may never get a fix. Plan to replace it, or declare the reasons for its API use yourself.
Writing your app's manifest
Create the file at ios/YourAppName/PrivacyInfo.xcprivacy. Add it to your Xcode project under the app target. Xcode 15+ has a template if you start from New File → Resource → App Privacy.
A minimal manifest looks like this:
The example declares: no tracking, no tracking domains, one collected data type (email, linked, used for app functionality), and one accessed API (UserDefaults, for the standard "same-app access" reason).
Fill in your real values. Don't copy-paste the example into a production app without verifying — the privacy nutrition label and the manifest need to match what your app actually does.
Common React Native libraries and their status
Checked September 14, 2026 against the latest npm packages and the native SDKs' source repositories. Check your installed versions before shipping.
| Library | Manifest status | Notes |
|---|---|---|
| react-native (core) | Template file since April 2024 (0.74.0, plus 0.71.19, 0.72.14, 0.73.8); React Native's own pods and bundled third-party pods ship manifests from 0.75.0 | Existing projects may need to add the template file |
| @react-native-async-storage/async-storage | In the package from 1.23.0 | Upgrade older versions |
| lottie-react-native, react-native-image-picker, react-native-device-info | In the package | Lottie is on Apple's list, so keep lottie-ios on a version that ships its manifest |
| @react-native-firebase/*, react-native-onesignal | None in the JavaScript wrapper; the Firebase and OneSignal iOS SDKs ship manifests | Firebase and OneSignal modules are on Apple's list. The native SDK version your wrapper pulls in is what counts |
| @sentry/react-native, react-native-purchases (RevenueCat) | None in the JavaScript wrapper; sentry-cocoa and purchases-ios ship manifests | Not on Apple's list; keep the native SDK current |
| react-native-reanimated, react-native-gesture-handler, react-native-screens, react-native-safe-area-context, react-native-svg | None in the package | Not on Apple's list. If App Store Connect flags an API category in one of them, declare the reason or upgrade |
| Unmaintained native modules | Varies | Most likely to be flagged and least likely to get a fix. Replace them or declare their API use yourself |
What rejection looks like
The App Store Connect messages you're most likely to see:
- ITMS-91053: Missing API declaration. Your app, or code bundled in it, uses a required-reason API without an approved reason in a privacy manifest. The message names the binary and the API category. Often appears after a library update starts calling a new API.
- ITMS-91061: Missing privacy manifest. A new app, or an update that adds an SDK, includes an SDK from Apple's list that has no privacy manifest.
- Missing signature. An SDK from Apple's list, added as a binary framework, isn't signed.
Find the SDK or code the message names. For an SDK on Apple's list, move to a version that ships its own manifest (and signature); Apple's guidance is that each SDK's manifest describes only that SDK. For a missing reason in your own code, or in a library compiled into your app, add the reason your code actually has. If a library has no fixed version, contribute one or replace it.
Pre-release privacy manifest sweep?
Audit your dependency graph before the next App Store submission. The free scanner shows which installed package versions have published security advisories. Privacy manifests still need a manual check of each native dependency.
Frequently Asked Questions
What is a PrivacyInfo.xcprivacy file?
PrivacyInfo.xcprivacy is a property-list file Apple introduced at WWDC23. It declares three things: which categories of user data your app or SDK collects, whether that data is linked to identity or used for tracking, and which "required reason" APIs the code calls, such as file timestamps, system boot time, disk space, and UserDefaults. Since May 1, 2024, App Store Connect doesn't accept new apps or updates that use those APIs without an approved reason, and SDKs on Apple's list of commonly used third-party SDKs need their own manifest when a new app includes them or an update adds them.
Does my React Native app need a privacy manifest?
In practice, yes. React Native itself uses required-reason APIs (file timestamps, UserDefaults, and system boot time), so your app has to declare reasons for them. The app template has included a privacy manifest since April 2024 (0.74.0, and the 0.71.19, 0.72.14, and 0.73.8 patches), and React Native's own pods ship manifests from 0.75.0; projects created earlier may need to add the template file. SDKs on Apple's list of commonly used third-party SDKs need their own manifest. Other libraries aren't required to ship one, but any required-reason API their native code calls still needs a declared reason.
Which React Native libraries are missing privacy manifests?
Many popular React Native libraries ship no manifest in their npm package, including Reanimated, Gesture Handler, Screens, and SVG as of September 2026, and none of those is on Apple's list. Manifests matter most for SDKs that are on the list, such as Firebase, OneSignal, Lottie, and SDWebImage, which reach your app through the native SDK version a wrapper depends on, and for any library whose native code calls required-reason APIs. To check, look for PrivacyInfo.xcprivacy files under ios/Pods and generate Xcode's privacy report from an archive.
What happens if I submit a React Native app without a privacy manifest?
App Store Connect rejects uploads that use required-reason APIs without an approved reason (ITMS-91053), and new apps or updates that add an SDK from Apple's list without its privacy manifest (ITMS-91061) or, for binary SDKs, its signature. For SDKs that aren't on the list, Apple encourages a manifest but doesn't require one. Apple can change the list, so check its third-party SDK requirements page before each release.
How do I add a privacy manifest to my React Native app?
Create a PrivacyInfo.xcprivacy file in your iOS app target (ios/MyApp/PrivacyInfo.xcprivacy). Add it to the Xcode project so it's bundled with the app. Inside, declare any data categories your app collects, mark whether each is used for tracking, and declare an approved reason for each required-reason API your code calls. The Xcode 15+ template generator gives you a starting file; you fill in the values that match your actual code.
What is a "required reason" API?
Apple has defined a set of API categories that historically were used to fingerprint users — file timestamps, system uptime, disk space, active keyboards, UserDefaults, and a few others. Since May 1, 2024, App Store Connect doesn't accept new apps or updates that call APIs in those categories without an approved reason in a privacy manifest. The list of approved reasons is in Apple's developer documentation. You pick the one that matches why your code actually calls the API.