iOS Privacy Manifests for React Native: the libraries that will fail your build
Apple introduced PrivacyInfo.xcprivacy in 2023 and began enforcing it in 2024. Your app needs one. Every third-party SDK it embeds needs one too.
React Native itself ships a manifest from 0.73 onward. Popular libraries have caught up. The unmaintained corner of the ecosystem hasn't, and that's where App Store Connect rejections come from.
The fix is concrete: audit, add manifests where missing, replace libraries that won't get one. The cost of ignoring it is a rejection during a release that was supposed to be routine.
You submit a build. App Store Connect sends back a warning email about "missing privacy manifest" for some SDK you've been shipping for two years. The build technically uploads but the email implies, with Apple's signature passive-aggression, that this won't last forever.
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. Using any API in those categories without declaring an approved reason in the manifest is grounds for rejection.
The enforcement timeline
| Date | What changed |
|---|---|
| WWDC 2023 | Apple announced privacy manifests and the required-reason API framework |
| Spring 2024 | Apple began emailing developers about missing manifests on a list of "commonly used SDKs" |
| May 2024 | App Store Connect began rejecting builds with missing manifests for SDKs on Apple's commonly-used list |
| 2025 | Enforcement expanded — manifests required for binary signing of third-party SDKs, missing reasons elevated from warnings to errors in more cases |
| 2026 | Steady-state enforcement. Missing manifests on libraries that touch required-reason APIs reliably fail uploads |
Apple has consistently tightened over time. Anything currently a warning is on a path to being a hard rejection. Treat it that way.
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 like CA92.1 ("Access info from same app, per documentation") or 1C8F.1 ("Access for declared app functionality"). Pick the code that matches your actual reason. Don't lie.
What React Native handles for you
React Native shipped its own privacy manifest in 0.73 (December 2023). It covers the required-reason APIs that the framework itself calls — file timestamps for the bridge cache, UserDefaults for internal config, system boot time for performance instrumentation, and so on.
If you're on 0.73 or later, the framework's contribution to the privacy manifest story is handled. You don't have to add a manifest entry covering React Native's internal API usage.
What's still on you:
- Your app's own code, anywhere you call a required-reason API
- Every third-party React Native library that ships native code
- Every non-React-Native iOS SDK you also embed (Firebase, Sentry, etc.)
The third-party library piece is where the audit lives.
If you're below React Native 0.73, you don't have the framework manifest. The fix is upgrading. There's no realistic way to backport the framework's manifest into older versions and have it actually cover the right APIs.
How to audit your dependencies
The audit is a script. Walk your CocoaPods install directory and look for which pods include a PrivacyInfo.xcprivacy file.
Compare the list of pods to the list of pods with manifests. The diff is your audit list.
For each library without a manifest, decide:
- Is it maintained? Check the last release date. If it's more than 12 months ago, treat the library as a likely casualty.
- Does it call required-reason APIs? Open the source. Grep for
UserDefaults,NSFileManager,systemUptime, and the other required-reason API patterns. If it uses none of them, the missing manifest is lower urgency. - Is there a newer version with a manifest? Often the library has been updated but you're pinned to an old version.
- Is there a replacement? For dead libraries, find a current alternative.
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
Snapshot as of 2026. Verify the current version's manifest before shipping.
| Library | Manifest status | Notes |
|---|---|---|
| react-native (core) | Shipped since 0.73 | Covers framework's internal API usage |
| @react-native-firebase/* | Shipped | Updated across all Firebase modules |
| react-native-reanimated | Shipped (v3.7+) | Upgrade if you're below this |
| react-native-gesture-handler | Shipped (v2.16+) | |
| @sentry/react-native | Shipped | Sentry was an early mover |
| react-native-purchases (RevenueCat) | Shipped | |
| react-native-onesignal | Shipped | |
| react-native-async-storage | Shipped (v1.21+) | Upgrade older versions |
| Older react-native-image-picker forks | Inconsistent | Check your specific fork; some are abandoned |
| Unmaintained navigation libraries | Missing | Migrate to React Navigation or react-native-navigation |
| Niche analytics wrappers | Often missing | Replace or wait for the underlying SDK to update and rewrap |
What rejection looks like
Three common shapes of App Store Connect feedback:
- Missing manifest, soft warning. Email from Apple naming the SDK, saying the manifest is missing or incomplete. Submission goes through. You're on a clock.
- Missing manifest, upload failure. ITMS-91056 (or similar) error during binary upload. The build doesn't make it past App Store Connect at all. Common for SDKs on Apple's commonly-used list.
- Missing required reason. ITMS-91065 (or similar) — the manifest exists but doesn't declare a reason for a required-reason API the code calls. Often appears after a library bumps to a version that calls a new API without updating the manifest.
The fix in each case is the same: identify the library, find a version that ships a complete manifest, and upgrade. If no such version exists, contribute one or replace the library.
Pre-release privacy manifest sweep?
Audit your dependency graph before the next App Store submission. The free scanner checks for known CVEs and outdated libraries — both of which correlate strongly with missing privacy manifests, because the libraries that haven't updated for security usually haven't updated for compliance either.
Frequently Asked Questions
What is a PrivacyInfo.xcprivacy file?
PrivacyInfo.xcprivacy is a property-list file Apple introduced in 2023 and began enforcing in 2024. 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. Required reason APIs include things like file timestamps, system boot time, disk space, and UserDefaults. Apps and SDKs that use those APIs without a manifest declaring an approved reason get rejected at App Store Connect submission.
Does my React Native app need a privacy manifest?
Yes. React Native itself ships a privacy manifest as of version 0.73, covering the APIs the framework uses internally. Your app needs its own manifest covering APIs your code calls directly. Every third-party SDK you embed needs its own manifest as well — and this is the most common failure point, because many React Native libraries haven't shipped one yet.
Which React Native libraries are missing privacy manifests?
The category that consistently lags is small or unmaintained libraries — older image pickers, older async storage forks, abandoned analytics wrappers, niche native modules. Popular and actively maintained libraries (React Native Firebase, Reanimated, Gesture Handler, Sentry, RevenueCat, OneSignal) have shipped manifests. The check is to run a script across node_modules and look for .xcprivacy files inside library bundles — anything that touches required-reason APIs but ships nothing will be flagged on upload.
What happens if I submit a React Native app without a privacy manifest?
App Store Connect emits warnings for missing or incomplete manifests. For SDKs on Apple's commonly used SDKs list, the manifest is enforced — uploads without one fail. For other SDKs and your own app code, you'll get warnings that escalate over time. Apple has tightened enforcement steadily since 2024. The safe assumption is that anything generating a warning today will be a hard failure within the next year.
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. Calling APIs in those categories without declaring an approved reason in your privacy manifest is grounds for rejection. The list of approved reasons is in Apple's developer documentation. You pick the one that matches why your code actually calls the API.