LaunchLint Academy
The short answer
- An Apple privacy manifest is a file named PrivacyInfo.xcprivacy. It describes privacy practices of app and third-party code in a standard format and includes approved reasons for certain required-reason APIs.
- In React Native and Expo, relevant calls often originate in native dependencies. Review your manifest, SDK versions, Pods, and the Xcode privacy report produced from the final release archive.
- The manifest does not replace App Privacy in App Store Connect, your privacy policy, or App Tracking Transparency consent when applicable. These layers must remain consistent with actual practice.
1. What PrivacyInfo.xcprivacy actually describes
Apple introduced privacy manifests so apps and SDKs can declare privacy practices in a machine-readable format. Xcode can aggregate embedded third-party manifests into a report, making it easier to inspect the SDK practices included in the final product and prepare more accurate App Privacy answers.
A manifest may contain collected-data categories, tracking domains, tracking behavior, and required-reason API access. Not every key belongs in every app. Do not copy a large sample blindly: each entry is a technical assertion about code shipped in the bundle.
| Layer | Job | Replaces the others? |
|---|---|---|
| PrivacyInfo.xcprivacy | Technical bundle declaration | No |
| Xcode privacy report | Aggregates bundle manifests | No |
| App Privacy | Public store data-practice answers | No |
| Privacy policy | Explains collection, use, protection, retention, and rights | No |
2. Required-reason APIs need an approved, actual reason
Some API categories can be abused for fingerprinting and therefore require an approved reason. Current examples include UserDefaults, file timestamps, system boot time, available disk space, and active keyboard APIs. Apple can extend the list and reasons, so use the current documentation.
A reason code is not free-form text. Select only an Apple-approved reason that matches the real use. Do not add one merely to silence a warning. If the app or SDK uses the API for a different purpose, correct the implementation or dependency.
3. Third-party SDKs are part of your submission
Apple maintains a list of commonly used SDKs for which privacy manifests and, for binary dependencies, signatures are required in specified submission cases. Components often found indirectly in React Native stacks include Hermes, Firebase libraries, GoogleUtilities, Protobuf, OneSignal, and SDWebImage.
You remain responsible for third-party code. Prefer updating a problematic SDK to a version with a correct vendor manifest. Do not use an app-level manifest to mask stale or wrong SDK declarations without understanding them. Record the version, source, embedded manifest, and enabled feature.
SDK review:
- Inventory direct and transitive native dependencies
- Check Apple’s affected-SDK list
- Read vendor guidance and release notes
- Locate manifest inside Pod or framework
- Account for signatures on binary dependencies
- Remove unused modules and stale versions
- Regenerate the final report after updates
4. Configure the manifest in Expo and React Native
With Expo Continuous Native Generation, configure the manifest under expo.ios.privacyManifests in app.json or app.config. In a bare React Native project, create PrivacyInfo.xcprivacy in the iOS project and add it to the correct target. This is native configuration, so an over-the-air JavaScript update is not sufficient.
{
"expo": {
"ios": {
"privacyManifests": {
"NSPrivacyAccessedAPITypes": [
{
"NSPrivacyAccessedAPIType":
"NSPrivacyAccessedAPICategoryUserDefaults",
"NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
}
]
}
}
}
}The example is not a universal template. Check CA92.1 and every other code against Apple’s current definition and the concrete access. For dynamic configuration, verify the resolved production values, commit the source configuration, and record the first build that contains it.
- Resolve production configuration
- Validate syntax and allowed keys
- Map each reason to actual use
- Assign the manifest to the correct target
- Create a new native binary
- Increase build number and validate again
5. The final bundle is the reliable evidence
A repository file proves intent only. The archived release contains Pods, frameworks, and resource bundles. Read the Xcode privacy report or inspect the archive to confirm which manifests are present and aggregated. Static CocoaPods dependencies can require special attention, and Expo documents limitations in automatic parsing.
Check every distributed target: main app, extensions, widgets, and notification service extensions can have separate dependencies. A correct main-target manifest does not repair a missing declaration elsewhere. Store the report, build number, and dependency lockfile as release evidence.
- Archive Release rather than Development
- Include app and extension targets
- Read the aggregated report
- Investigate unexpected types or tracking domains
- Match required-reason categories to use
- Assign upload warnings to the exact build
- Confirm the fix in the rebuilt artifact
6. Do not confuse manifests, App Privacy, and ATT
App Privacy publicly explains what the app and partners collect and how it is used. PrivacyInfo.xcprivacy is a technical bundle declaration. One can inform the other, but an SDK manifest cannot describe every first-party backend or dynamic behavior and does not automatically generate a complete store answer.
App Tracking Transparency is another layer. When data is used for tracking under Apple’s definition, consent may be required. An NSPrivacyTracking entry does not grant permission, and an ATT prompt does not replace an accurate label. Evaluate purpose, linking, and third-party access together.
7. Fix missing manifest declarations systematically
Map each warning to an API category and then to the responsible module. Search first-party native code, Pods, and frameworks, review vendor updates, and verify actual purpose. Only then change the manifest or dependency. This order prevents invalid reason codes and permanent workarounds.
LaunchLint can statically inventory privacy files, Expo configuration, SDK versions, and required-reason categories with file paths. It never builds user code, so it cannot claim to have seen the final Xcode report. A useful fix task separates repository evidence from manual bundle validation.
- Save warning and build ID
- Map category to module
- Validate the approved reason
- Update SDK or remove use
- Keep manifest narrow and correct
- Build a new release artifact
- Review Xcode report and upload result
- Update App Privacy and policy if needed
Frequently asked questions
Does every React Native app need its own PrivacyInfo.xcprivacy?
Not every app needs the same first-party entries. The relevant question is which APIs and SDKs are present in the final bundle; many projects need an app manifest or correct embedded SDK manifests.
Can I copy reason codes from another project?
No. A code is valid only when Apple’s approved reason matches the actual use. Copying can hide a warning while creating an inaccurate declaration.
Does the manifest replace the App Privacy label?
No. The manifest is bundle metadata; App Privacy is the public store declaration. The privacy policy and, where applicable, ATT remain separate requirements.
Can an OTA update fix a manifest?
No. PrivacyInfo.xcprivacy is part of the native iOS artifact. Correct it in a new binary with a higher build number.