[Action Required][iOS] Privacy Manifest

[philIip]

tldr: Apple will require all iOS apps to have a privacy manifest. This doc summarizes the actions you will need to take for your React Native apps and libraries.

Context

What is a privacy manifest?

From the Apple docs:

“Apps and third-party SDKs — distributed as XCFrameworks, Swift packages, or Xcode projects — can contain a privacy manifest file, named PrivacyInfo.xcprivacy. The privacy manifest is a property list that records the types of data collected by your app or third-party SDK, and the required reasons APIs your app or third-party SDK uses. For each type of data your app or third-party SDK collects and category of required reasons API it uses, the app or third-party SDK needs to record the reasons in its bundled privacy manifest file.”

From this description, the privacy manifest has two main components:

• The data the app or third-party SDK collects
• The reasons for usage of the required reasons APIs

What about React Native?

React Native is distributed in a variety of ways, but it is usually built as source with React Native apps, and not as a 3rd-party distributed SDK. This means that the privacy manifest for the SDK is not required to be provided by the framework, but the application. We'd like to make that simpler for you.

Timeline

Apple announced two dates when it comes to Privacy Manifests.

• Starting March 13th: E-mail notifications for apps using required reasons APIs. Here’s an example of one of the notifications.
• Starting May 1st: App submissions will require a privacy manifest.

Framework solutions

React Native

Targeting the end of next week, we are going to provide the following pipeline: During the pod install step, we will generate a template of the privacy manifest if your app does not already have one. This template will be pre-populated with the required reasons of the required reasons APIs used within the React Native framework. For those already with a privacy manifest, you can either copy and paste the template content into your app's privacy manifest, or we will provide the privacy manifest in React Native's resource bundles. The app owner will fill out the necessary remaining content. This functionality will be backported into our support window.

Note that currently, apps being submitted are inconsistently evaluating the privacy manifest in the podspec's resource bundle. Currently, we suggest copy and pasting the reasons provided by the library author into your final privacy manifest.

Ultimately, it is up to the app author to make sure the privacy manifest(s) included in their app bundle are complete and correct.

Update: The template generation has been added to the post_install hook in cocoapods in facebook/react-native@d39712f. This has been picked into 0.71 - 0.73. See #776 (comment) for details.

Update 2: @aleqsio built resource bundle aggregation into the pod install script! facebook/react-native#44214

Hermes

We have spoken with representatives at Apple, and they have informed us that the hermes SDK on the commonly-used SDKs list is referring to another Hermes, not the one made by Meta. They are referring to this one: https://github.com/Imgur/Hermes/blob/master/README.md. As such, Facebook/hermes is not required to provide a Privacy Manifest and Signature ahead of the May 1 date for this SDK. You will be able to continue to submit versions of your apps that use Facebook/hermes without disruption beyond that date, based on current policies.

Next Steps

If you are the owner of a React Native app or maintain a React Native library, we encourage you to do the following:

• Read the following Apple documentation on Describing data use in privacy manifests and Describing use of required reason API.
• If your app collects user data, document the data types that correspond to the type of data that your app is collecting. This will need to be part of the application's privacy manifest.
• If you are using any of the required reason APIs outside of the React Native framework, document the API and the reason code for the reason you are using this API. This will also need to be part of the application's privacy manifest.

For library maintainers

After determining the privacy manifest content for your library, we recommend that you also determine how users of your library should integrate your privacy manifest content. This may depend on how the library is being linked. You can also instruct consumers of your library to copy and paste the privacy manifest content into their application's. If your library is integrated via Cocoapods as a separate SDK bundle, you can use the resource_bundles on the spec to link the privacy manifest content of your library - however as of now, the archive is capturing the data use but not the required reasons. You will need to add the required reasons to your app's privacy manifest.

---

Please feel free to comment below if you have any other questions or comments, I will do my best to answer them! Thanks for reading.

[gabrielguilhoto]

Thanks for the clarification. What I understood is:

• If my app uses a library that is integrated via Cocoapods as a separate SDK bundle, I don't need to cover what the library does in the privacy manifest of my app
• If my app uses a library that is not integrated via Cocoapods as a separate SDK bundle, I do need to cover what the library does in the privacy manifest of my app

Is that correct? If it is, how can I know if a library is integrated via Cocoapods as a separate SDK bundle?

[philIip]

Hi @gabrielguilhoto, thanks for your questions! I believe you have the right idea.

If my app uses a library that is integrated via Cocoapods as a separate SDK bundle, I don't need to cover what the library does in the privacy manifest of my app

This is technically supposed to be true, but currently it is complicated. If the SDK is distributed as a 3rd party SDK, then you don't need to worry about it - the privacy manifest in the framework bundle will be evaluated separately. If the framework is linked as part of your application's source code, there have been many reports that Apple is not parsing through all of their individual privacy manifests. This might change in the next month, but in case it doesn't, I recommend copy and pasting the privacy manifest into your application's. That's why we are prioritizing putting the React Native privacy manifest content into the application's with this template process.

If my app uses a library that is not integrated via Cocoapods as a separate SDK bundle, I do need to cover what the library does in the privacy manifest of my app

Yes. Since the SDK is statically linked and therefore part of the same namespace as your application code, there's no way to differentiate what code you wrote and what code was forked and copied.

how can I know if a library is integrated via Cocoapods as a separate SDK bundle?

I think if the podspec for the library has static_framework = true, or use_frameworks = true, the library should be integrated in it's own bundle.

[gabrielguilhoto]

Thanks for the explanation @philIip ! Some questions:

If the SDK is distributed as a 3rd party SDK, then you don't need to worry about it - the privacy manifest in the framework bundle will be evaluated separately. If the framework is linked as part of your application's source code, there have been many reports that Apple is not parsing through all of their individual privacy manifests

My understanding is that being "linked as part of your application's source code" is different from being statically linked. Is that it? So there would be 3 kinds of libraries (3rd party, linked as part of the application's source code, and statically linked).

If that is the case, how can I differentiate between those 3? As for the provided guidance:

I think if the podspec for the library has static_framework = true, or use_frameworks = true, the library should be integrated in it's own bundle.

Does that mean that if a library has static_framework = true or use_frameworks = true in the podspec, then it is a "3rd party SDK" (and so its usage should not be considered in my app's privacy manifest)? Or could it also be a "framework linked as part of application's source code" (so I should consider it in my app's privacy manifest if Apple behavior doesn't change)?

[philIip]

My understanding is that being "linked as part of your application's source code" is different from being statically linked.

Static linking is a subset of the many ways you can link code as part of your app's binary. Some dynamically linked code can also be part of your app's binary - very often, the dynamic lookup will page in code that exists in your app's binary. Sometimes dynamically linked code is paged through the operating system (like UIKit, for example - a copy of UIKit is not included in every iOS app).

In the case of privacy manifests, you are responsible for all of the code that is included with your app's binary.

Does that mean that if a library has static_framework = true or use_frameworks = true in the podspec, then it is a "3rd party SDK

I don't think you can assume that from this flag. What you do know is that if either of these framework flags are turned on, then Cocoapods will make this SDK live in it's own bundle, rather than in the same namespace as the rest of your app's source code. It doesn't say anything about where we are getting this code from.

So the question we are trying to answer is how do we know where this framework code lives? I know you're asking me for something more explicit, but I don't actually know off the top of my head if there's an easy way to check this. I will ask around on my team, but maybe someone in the community has the answer.

For now, Apple has provided a list of SDKs that are required to provide the manifest file themselves: https://developer.apple.com/support/third-party-SDK-requirements/.

[philIip]

@gabrielguilhoto here's how you can tell if the files are brought in as source code vs from somewhere else.

in this screenshot, DoubleConversion is brought in as source. you can see its source files listed in xcode and you can access them and read them. in the case of hermes, which is brought in remotely, you only can access the framework. you can't see the internal files.

[gkasireddy202]

Any chance of Apple extending the date for the Privacy Manifest policy?
Most third-party SDK developers have not uploaded their manifest files.Any thoughts?

[philIip]

Hi @gkasireddy202! Unfortunately, the React Native team would not have any insight into the timelines - we are just as clueless as you are.

If a third-party distributed SDK has not uploaded their manifest file, it is on them to provide this. Your app presumably does not contain the implementation files for that SDK as they would be delivered from elsewhere, so when you submit your app, I would expect that code would not be included as part of your app review.

If you are building the SDK as part of your app, you have a few options. One would be to evaluate the library yourself and use your best judgment on the required reasons and data collection entries for that library. Another would be to file an issue with the library owner to escalate in order for them to prioritize providing the manifest entries for their consumers.

[gkasireddy202]

@philIip - Thanks for your information.My project has react-native:0.68.7.Can I upgrade my project to above 0.71?
Has the react-native team added the iOS manifest file above 0.71 versions?

[philIip]

Since the latest stable is 0.73, I believe the support window will be for 0.73, 0.72, and 0.71. I will be targeting 4/5 to land those changes in those versions. If updating is too much work in this short window, I will be documenting manual steps for what the tooling will do.

[tdraper-dev]

@philIip -- thanks for all your efforts!

Following up -- any updates re: getting the Privacy Manifest template generation into the pod install step? Specifically, if possible, for RN version 0.72.x. Currently, in releases, I see it on the 0.74 release candidate

[gkasireddy202]

@philIip - Can I update to version 0.73 after adding your changes to 0.73?

[Yogiyadavmca]

@philIip Will the RCT-Folly pod be considered a third-party SDK? I have run the ios_17_required_reason_api_scanner script on the code and found that the RCT-Folly pod is using the "File timestamp APIs." Do we need to include the reason in our code, or will React Native include the PrivacyInfo.xcprivacy file in it? My react-native version is 0.71.7.

[philIip]

Hi @Yogiyadavmca, the template will include the privacy manifest content for all of the forked frameworks that React Native is also bringing in, such as RCT-Folly and boost.

[misbell]

Hi Phillip, has this been done yet, and if so, where is the template located?

Thanks for the work on this!

[misbell]

Also, we're using pod 1.14 because of issues with 1.15. Will your template creation still work?

[cipolleschi]

Hi @misbell!
This is the commit where @philIip added the privacy manifest.

For the Cocoapods question, yes, it should work. We don't set a strong requirement for Cocoapods. You can track the requirements here. As you can see, the template won't work with Cocoapods 1.15 either.

I, anyway, strongly suggest that your team starts using Ruby bundler to manage the Ruby gem dependencies (including Cocoapods) so that if we push any change in the setup (e.g. forcing some version of some Gem dependency) they will be picked up automatically.

[ihiteshkumar]

@philIip As Apple provided this list and "hermes" is also there in the list. https://developer.apple.com/support/third-party-SDK-requirements/
Is the hermes considered a third-party SDK? Can you please confirm React Native will share privacy manifest for "hermes" also?

[cipolleschi]

Hi @ihiteshkumar, for Hermes, we still have to clarify some details. Expect to have some more information regarding it by the endo of the week/early next week!

[philIip]

i've updated the OP with the following:

We have spoken with representatives at Apple, and they have informed us that the hermes SDK on the commonly-used SDKs list is referring to another Hermes, not the one made by Meta. They are referring to this one: https://github.com/Imgur/Hermes/blob/master/README.md. As such, Facebook/hermes is not required to provide a Privacy Manifest and Signature ahead of the May 1 date for this SDK. You will be able to continue to submit versions of your apps that use Facebook/hermes without disruption beyond that date, based on current policies.

tldr: don't worry about hermes for may 1 deadline

[gkasireddy202]

@philIip - Thanks for your update.
Is there any chance that Apple will extend the May 1 deadline?
Some third-party libraries are not added manifest files.

[cipolleschi]

@gkasireddy202 We have no extra information regarding Apple postponing the deadline.
However, Apple clarified that the Manifest requirement will be enforced for new apps and for new dependencies in existing apps, as they mention here:

[...] when you submit new apps in App Store Connect that include those SDKs, or when you submit an app update that adds one of the listed SDKs as part of the update.

So, if you want to push an update for your app adding a new dependency from the list provided by Apple, the new dependency must provide the Manifest and must be signed.
If your app is already using those dependencies, you don't need to provide the privacy manifest.

Concretely, if your app is already using Firebase (for example) you don't need to add the privacy manifest. If you are adding Firebase to an existing app, you need the privacy manifest. If you are publishing a new app that uses Firebase, you need the privacy manifest.

I hope this help and gives you more breath.

[bang9]

How about utilizing tools that merge options of dependencies, such as react-native.config.js of react-native-cli or reactNativeManifest, when extracting Privacy manifest templates to support data use?

This approach is similar to Expo's plugins.
Expo plugins documentation
Expo pull request

[bang9]

When it comes to providing a Privacy manifest due to data usage for libraries that only require JavaScript files to be installed, using Cocoapods is perhaps the best option available. However, it may feel somewhat awkward to provide this for libraries that consist solely of JavaScript files.

[aleqsio]

Working on supporting xcprivacy files for Expo, for now we're also not seeing aggregation working for cocoapods.

Let's hope this gets fixed by apple, but till then I'm considering the following aggregation step, provided as a cocoapods script (probably easy to adapt for react-native core):
expo/expo#28091

[KavyaShrivastava]

What versions of react-native will be supported?

[15matias15]

@ruanb7 how do you get and updated permission declaration? just updating a new version into testflight? or only when the app is published, you'll get the report.

[aleksamrakovic]

also curious, how we know if we set them correctly?

[christocracy]

how we know if we set them correctly?

• publish to TestFlight
• Add app to “external test group”

If your privacy interrogation fails, you’ll get an email about a minute later.

[cipolleschi]

@ruanb7 check this comment. It is likely that Hermes is the responsible for those API, but we are aware and we will release new versions of Hermes with new React Native versions in the near future.

[gkasireddy202]

is the version:0.68 support for the iOS privacy manifest.?
Please update on this.

[christocracy]

NSPrivacyAccessedAPICategoryDiskSpace

Accessing disk-space is not an unusual thing to do for a plug-in that might deal with files (eg a SQLite plugin). These APIs are not “dangerous” or unusual to be used but with Apple turning the screws on “App Tracking”, the “bad guys” have had to resort to attempting to “fingerprint” a device across apps by taking advantage of the system clock and file timestamps. Another flagged api is NSUserDefaults, which is a commonly used key/value store, much like the browser localStorage.

for now, I would not seek a deeper understanding about the “why”, just add those api items to your PrivacyInfo file and work on satisfying Apple’s privacy interrogation. Once your App passes privacy interrogation, then go on a deeper quest on the who and why.

[cguino]

We have spoken with representatives at Apple, and they have informed us that the hermes SDK on the commonly-used SDKs list is referring to another Hermes, not the one made by Meta. They are referring to this one: https://github.com/Imgur/Hermes/blob/master/README.md. As such, Facebook/hermes is not required to provide a Privacy Manifest and Signature ahead of the May 1 date for this SDK. You will be able to continue to submit versions of your apps that use Facebook/hermes without disruption beyond that date, based on current policies.

Imgur/hermes is an old pod using swift 2.2, last update Jul 2015, archived repo, declared not maintained for 7 years...
Why would imgur/hermes be considered as "commonly-use" and meta/hermes wouldn't ?
How Apple can make the difference between those two frameworks ?

[cipolleschi]

We don't know which process Apple followed to decide which frameworks are commonly used. They have not shared this information, but they confirmed to us that facebook/hermes is not among those and the hermes they are referred to is imgur/hermes. We too were lead to believe differently because that package was not exposed to Cocoapods and, as you mentioned, is unmaintained.

[philIip]

@cguino it is not really something that we know the answer to. apple has told us that this is the case and gave us permission to communicate so in writing.

[iaroslav-ianishyn]

i believe i don't use Imgur/hermes, i have hermes-engine which appears to be integral part of react-native as i understood.
hermes-engine (0.72.2), React-Core (0.72.2)

this hermes.framework has reason required API usage and requires Privacy manifest:
API '_fstat' is used in the binary; of category: NSPrivacyAccessedAPICategoryFileTimestamp
API '_fstatfs' is used in the binary; of category: NSPrivacyAccessedAPICategoryDiskSpace
API '_lstat' is used in the binary; of category: NSPrivacyAccessedAPICategoryFileTimestamp
API '_stat' is used in the binary; of category: NSPrivacyAccessedAPICategoryFileTimestamp
API '_statfs' is used in the binary; of category: NSPrivacyAccessedAPICategoryDiskSpace

[cipolleschi]

We are aware of this. facebook/hermes on main already removed the usage of those APIs thanks to these two commits:

• facebook/hermes@b686d8f
• facebook/hermes@c7debcc

Closer to the deadline of the 1st of May, we will release new versions of React Native and Hermes binaries, where we will backport these commits to those versions, to remove the usage of those APIs from the Hermes codebase.
At that point, Hermes will not use any privacy-sensitive API and it will not require a Privacy Manifest.

[gkasireddy202]

What versions you will backport for iOS Privacy manifest?

[CatWithNineLives]

@cipolleschi Thanks for the answer! We can't update the react-native version to v0.74.0 for now to get this version of hermes which doesnot use these APIs, as a result we'll have to add NSPrivacyAccessedAPICategoryDiskSpace in our Privacy Manifest. Just confirming, will reason E174.1 be enough?

E174.1
Declare this reason to check whether there is sufficient disk space to write files, or to check whether the disk space is low so that the app can delete files when the disk space is low. The app must behave differently based on disk space in a way that is observable to users.

Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception that allows the app to avoid downloading files from a server when disk space is insufficient. 

[15matias15]

I'm already in 0.74 and notice that those commits were already merged on hermes/0.74.1. When is going to be released on RN side?

[mthomas100]

When running the ios_17_required_reason_api_scanner , an output similar to the following can be observed
Used symbols in binary ./Release-iphoneos/React-RCTImage/RCTImage.framework/RCTImage: mach_absolute_time

mach_absolute_time is a required reason API categorized as a "System boot time API" in the NSPrivacyAccessedAPICategorySystemBootTime category.

Are there any plans for addressing the usage of this required reason API?

[philIip]

@mthomas100 this reason will be covered in the template:

facebook/react-native@d39712f?fbclid=IwAR0hozrbkckW3xpQ3GlRbllzJ2cCBvD_ZQYlxMd-FMsaWRFZ9vnR4qHeXuM#diff-0891422f423f7d19877f724d9836a6849cd36cb15b899b6164f4f440cb5ff1af

[gkasireddy202]

Hi,

My project has react-native:0.68.7 and also maintained good stability in production.
Is this iOS privacy manifest file add in 0.68.7 by react-native ?

[ken0nek]

@tdraper-dev This is the React Native Privacy Manifest template file.

[tdraper-dev]

Ah, thanks for that @ken0nek

[nkleidis]

There seems to be an open and closing array section in the template that doesn't seem right

<array>
</array>

[cipolleschi]

It's ok. open/close tags, as long as they are valid should not influence the validity of the manifest.
For full context, the PrivacyManifest we provide is a template: you might have to add extra reasons depending on your apps. That might mean populating that array.

[SarjuHansaliya]

I created a PrivacyInfo.xcprivacy file and added those types & reasons mentioned in Apple email and voila its working 💪 . I think at this point Apple is probably not checking for all SDK used in the app as long as its reasons are mentioned in app's Privacy manifest file itself.

[SarjuHansaliya]

Here is my PrivacyInfo.xcprivacy file incase it helps someone.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>NSPrivacyAccessedAPITypes</key>
	<array>
		<dict>
			<key>NSPrivacyAccessedAPITypeReasons</key>
			<array>
				<string>E174.1</string>
				<string>85F4.1</string>
			</array>
			<key>NSPrivacyAccessedAPIType</key>
			<string>NSPrivacyAccessedAPICategoryDiskSpace</string>
		</dict>
		<dict>
			<key>NSPrivacyAccessedAPITypeReasons</key>
			<array>
				<string>CA92.1</string>
				<string>1C8F.1</string>
			</array>
			<key>NSPrivacyAccessedAPIType</key>
			<string>NSPrivacyAccessedAPICategoryUserDefaults</string>
		</dict>
		<dict>
			<key>NSPrivacyAccessedAPIType</key>
			<string>NSPrivacyAccessedAPICategorySystemBootTime</string>
			<key>NSPrivacyAccessedAPITypeReasons</key>
			<array>
				<string>35F9.1</string>
			</array>
		</dict>
		<dict>
			<key>NSPrivacyAccessedAPITypeReasons</key>
			<array>
				<string>C617.1</string>
			</array>
			<key>NSPrivacyAccessedAPIType</key>
			<string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
		</dict>
	</array>
	<key>NSPrivacyCollectedDataTypes</key>
	<array/>
</dict>
</plist>

[philIip]

@SarjuHansaliya essentially what is happening is that for each required reasons API, the review process looks for a required reason corresponding to that API. in that way, you can "over-declare" the required reasons to make the manifest acceptable, but that is up to your own judgement.

[philIip]

The privacy manifest template has been picked into 0.71 - 0.73. It should generate the following template in facebook/react-native@d39712f which will cover all of the required reasons in the React Native framework. You will have to manually add this generated file to the app bundle via XCode.

Feel free to manually create the file yourself as described by @christocracy and copy and paste the reasons from the commit if you are unable to upgrade your copy of RN to the support window.

To make sure the privacy manifest is properly linked, you can go to Product -> Archive in XCode. Then, right click the archive and select "Generate Privacy Report". If the report has no error, it means that the privacy manifest has been linked successfully.

Remember you are responsible for figuring out the reasons for other APIs that are brought in from outside of React Native, whether it's something you wrote or from a copy of a framework in your app's source code. Please consult the docs here: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_data_use_in_privacy_manifests?language=objc in order to figure those out.

[KeiSugiyasu]

I can’t find the related commit on 0.71 branch…

[gkasireddy202]

@philIip - Thanks.
Can I add the below temples in my project PrivacyInfo file?
facebook/react-native@d39712f

[philIip]

@KeiSugiyasu whoops, thanks for calling out. seems the pick is still pending. it is in 0.72 - 0.73 though.

@gkasireddy202 yes you can.

[wonderlul]

I'm dealing with "Multiple commands" issue as well, but it's kind of different because it's not caused by third-party library but rather my NotificationService. Can someone help me with that?

In emails from Apple I was notified that not just my app is missing declarations but also "PlugIns/NotificationService.appex/NotificationService".

When I'm adding App Privacy manifest, I'm checking the main app target but also NotificationService which is then added as target dependency as Build Phase. So logically there is multiplication of commands. Though if I won't choose NotificationService as target when creating the App Privacy manifest, I still receive warnings from Apple that API declaration is missing.

[wonderlul]

@cipolleschi thank you for your response.

NotificationService has it's privacy manifest. Before I'll include the screenshot of current implementation, I'll show you my NotificationService first:

Below as I said is the current implementation of privacy manifests:

[wonderlul]

Here are most of the warnings:

[wonderlul]

Update: when I change name of "PromotonsPrivacyInfo" to just "PrivacyInfo" it turns to be OK. Yet like I said, I can't name the other manifest the same because of the configuration (that I included above) because I'm getting issues about multiplication of manifest.

[cipolleschi]

@wonderlul I'm not sure I got the final answer, but have you managed to solve the issue completely?
Unfortunately, I think that Apple is pretty picky and wants all the privacy manifest to be called PrivacyInfo.xcprivacy.

There is not much we can do in that regard...

[wonderlul]

@cipolleschi
As the matter of fact I did and I'm SO angry with myself...

I have two folders inside my root "ios" folder called "Promotons". Would you look at the path of both folders...

So basically I moved the file inside ios/{PROJECT_NAME} and that works.

[bang9]

Slightly off-topic, but here's a tip for urgent ppl:
Using applications like https://wemakeapps.net/manifest-maker can help you quickly address Required Reason APIs.

[Mihai-github]

Did anyone get this error after adding the PrivacyInfo file and trying to do a build for testing?

❌ error: Multiple commands produce '/Users/builder/Library/Developer/Xcode/DerivedData/APP-astjpotccmrftsebuxjhqlzufvhq/Build/Intermediates.noindex/ArchiveIntermediates/APP/InstallationBuildProductsLocation/Applications/APP.app/PrivacyInfo.xcprivacy'

[Mihai-github]

Hey,sadly my app haven't integrated Sentry yet, do you know any way how can I see witch package is causing the issue for me?

[cipolleschi]

Usually, if you build from Xcode rather than from the Cli, you can inspect Xcode errors and it should tell you which commands were running. Hopefully this can help you in the investigation! 🤞

[sntg-p]

Since updating Sentry and RN Firebase packages and, removing Sentry's PrivacyInfo.xcprivacy file from the build phase I no longer have this problem.

[jbarrera2021]

I have this same problem, I followed the steps that are documented, but when compiling I still get this error.

[fredikey]

In my case, the causes of the error were Sentry and react-native-branch
Updating to the latest versions fixed the issue

[crherman7]

Can anyone explain why the PrivacyInfo.xcprivacy file was included only as a PBXFileReference and not also added as a PBXBuildFile to be applied to the app target in the commit at facebook/react-native@2d84d83?

[philIip]

hi @crherman7 this is probably a mistake on my part! that was mainly for reference, tho it probably makes sense to hook it up to the build system for the CLI! but our main focus is investing in the template generation for the post_install hook for pod install, which everyone has to run regardless. please lmk if there are any issues with that!

[crherman7]

@philIip, thanks for the prompt response! I just wanted to ensure I wasn't missing something in my assessment when using the latest react-native version (v0.74.0). I tested it via the CLI, and although the manifest exists, it's not included in the Copy Bundle Resources build phase. This oversight could potentially lead to Apple flagging the app for missing APIs for the most basic app assuming they don't have a third party SDK installed that covers the required reasons. Minimally, I believe documenting the need to add it to the correct build phase would help ensure it's bundled correctly, allowing Apple to aggregate the necessary reasons.

Most people won't have this issue assuming they already have a React Native project and are adding it via Xcode. This will be more helpful to new projects or idempotent ephemeral native code generation tools that generate the project for you.

Regardless, I appreciate your hard work and attention to this new requirement. It has been immensely helpful!

[15matias15]

I can confirm that adding the manifest with 0.73.7 and pod install you will still get the warning email from iOS, I added now through xcode and submit a new version for beta release to see if the warning is gone.

[Daha62]

I have successfully gotten rid of these annoying warnings. Created privacy manifests for all targets where I had them.

[fxamauri]

I’ve proposed adding useful content to facilitate version updates and help with the upgrade process. What do you think? Here’s the pull request for reference: PR #383

[mtr1012]

I'm on 0.72.3, how can I deal with the privacy requirement?

[mtr1012]

How about React Native and its dependencies? I think it needs to be updated too. Is it right?

[15matias15]

there was an update for 0.72 check it

[mtr1012]

Thank you so much <3

[Ahsanali012]

I am with react native version 0.72.3. I get this error when i do pod install

[Privacy Manifest Aggregation] Appending aggregated reasons to existing PrivacyInfo.xcprivacy file.
[Privacy Manifest Aggregation] Reading .xcprivacy files to aggregate all used Required Reason APIs.
Error during react_native_post_install: undefined method `new_file' for an instance of Xcodeproj::Project::Object::PBXFileReference

what needs to be done to fix this issue?

[liamjones]

@Ahsanali012 you need a backport of this PR: facebook/react-native#44390

[15matias15]

I was able to partially get rid of the warning email, I update rn, firebase, facebook and others sdk and create my own manifest, but when I upload to external test on testflight, I'm still getting the email but only for NSPrivacyAccessedAPICategoryDiskSpace. Does anyone else have this issue? I run the api_scanner but didn't print any usage of that API.

[15matias15]

react native firebase sdk (js), the one from invertase. And yeah, I updated to 1.9.20 and still get those warnings

[15matias15]

I'm using crashlytics and thinking if I should add this reason on NSPrivacyAccessedAPICategoryDiskSpace API

7D9E.1
Declare this reason to include disk space information in an optional bug report that the person using the device chooses to submit. The disk space information must be prominently displayed to the person as part of the report.

Information accessed for this reason, or any derived information, may be sent off-device only after the user affirmatively chooses to submit the specific bug report including disk space information, and only for the purpose of investigating or responding to the bug report.

or only with this is enough

E174.1
Declare this reason to check whether there is sufficient disk space to write files, or to check whether the disk space is low so that the app can delete files when the disk space is low. The app must behave differently based on disk space in a way that is observable to users.

Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception that allows the app to avoid downloading files from a server when disk space is insufficient.

[cipolleschi]

@15matias15 I can speak for crashlytics, but it is likely that Hermes is the responsible.
Have a look at this Comment and corresponding answers.

TL;DR: We need to cherry pick the commits in Hermes and we need to create new binaries for hermes to get rid of those.

[15matias15]

@cipolleschi yeah, I already updated react-native-firebase that use latest 10.24 firebase and notice there that they removed a lot of this methods

[15matias15]

just wonder which reason to put

[tubakhxn]

Working on supporting xcprivacy files for Expo, for now we're also not seeing aggregation working for cocoapods.

Let's hope this gets fixed by apple, but till then I'm considering the following aggregation step, provided as a cocoapods script (probably easy to adapt for react-native core):
expo/expo#28091

[cipolleschi]

There is already a PR against React Native core for that: facebook/react-native#44214

[a-riva85]

Any update on the relase date for the 0.71 branch?

[15matias15]

@a-riva85 check

[cipolleschi]

0.71.19 has been released today.
It contains the PrivacyManifest and a new version of Hermes without the disk access RR API.
Release

We are releasing 0.72.14 and 0.73.8 with similar commits.

[15matias15]

@cipolleschi thanks for pushing the new versions

[KavyaShrivastava]

Hi, I am facing an error that's showing up in the privacy report: Missing an expected key: 'NSPrivacyCollectedDataTypes' AppName/PrivacyInfo.bundle/PrivacyInfo.xcprivacy. The file is located in the path AppName/PrivacyInfo.xcprivacy (exactly like the react-native cli template). The file is also in Copy bundle resources. The report has all the collected data types and it's showing up in the privacy report but in the end, it's also throwing this error.

[cipolleschi]

cc. @philIip
@KavyaShrivastava can you confirm that you have these lines in your privacy manifest?

[KavyaShrivastava]

@cipolleschi Yes, I do in the file with the path 'AppName/PrivacyInfo.xprivacy', and the privacy report also shows all the data types listed in the array. The error seems to be within the path 'AppName/PrivacyInfo.bundle/PrivacyInfo.xprivacy'.

[ashwanihundwani1986]

@KavyaShrivastava @cipolleschi I am in touch with OT support will update if this is resolved by them. It is still not clear if these changes are passing the review

[philIip]

hmm, i wonder if since you generated the file via xcode, it expects it to be under this PrivacyInfo bundle - i'm not sure what that is! i wonder if you would get a different approach if you created the manifest separately, then added it via Add Files... instead

[ashwanihundwani1986]

@KavyaShrivastava @cipolleschi
OT team confirmed that the fix is in their latest version. I do not see any warnings further.

[mtr1012]

Just uploaded a build to AppStore and have no issue although I haven't updated anything. Maybe the deadline has been extended by Apple?

[mtr1012]

I have no warning email. Can't understand what's going on 😂

[liamjones]

I wonder if it's down to this wording (emphasis mine): https://developer.apple.com/news/?id=pvszzano

Starting May 1, 2024, new or updated apps that have a newly added third-party SDK that‘s on the list[...]

You could read that as; existing apps, with existing SDKs won't have an issue but as soon as you add a new SDK to your existing app you have to add the privacy manifest info. E.g. old apps with their existing SDKs get grandfathered into a "it's already been accepted" behaviour. I don't know if this is true, it's just a guess based on the wording above.

[cipolleschi]

I can confirm what @liamjones says.
During our call with Apple, they stressed that the rules will be enforced on

• new apps
• old apps with new dependencies from the list above.

So, old apps with no new dependencies, will go through even without the privacy manifest.

[ashwanihundwani1986]

@cipolleschi Will the old apps with old dependencies see the warnings still? I was seeing those yet till yesterday

[cipolleschi]

Potentially yes. I don't think that Apple is tracking what you had before: they just emit the warnings programmatically, but they are safe to ignore for old apps with old dependencies.
They even mentioned that old apps that update a dependency, can actually ignore the warning.
So, if your App depends on library A@1.0.0 and you bump A to 1.0.1, you don't have to add the privacy manifest.