Implement privacy manifest aggregation

[aleqsio]

Summary:

As of now, Apple does not respect privacy manifests added as cocoapods resource bundles. This forces react-native developers to manually copy .xcprivacy files content for each native dependency that accesses restricted reason APIs to the root file.

This PR adds an aggregation step that crawls through pod dependencies to collect all reasons into the root privacy info file.

Changelog:

[IOS][ADDED] – Add privacy manifest aggregation.

Test Plan:

When run on RNTester, it appends aggregated entries (while keeping existing ones) to existing .xcprivacy file without modifing .pbxproj:

When run on RNTester with the xcprivacy file removed from xcode beforehand, it creates a new .xcprivacy file, and adds it to Compile Bundle Resources in the same way as in the new template:

When run on RNTester with an empty .xcprivacy file, it appends aggregated entries from pods AND reasons for react-native core.

When run with privacy_file_aggregation_enabled: false in use_react_native, it falls back to existing behavior:

[facebook-github-bot]

@philIip has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[philIip]

this is awesome!

[philIip]

feels we can reuse ensure_reference here

[aleqsio]

I guess it depends on what we want this logic to do:

1. Place the manifest outside of the project, and inform the user that they need to copy it manually and add their reasons? – we don't want to reference it if we don't place it in the project.

2. Create a manifest with RN reasons inside the project (so not user_project.path.parent) and auto reference it?
   If so, perhaps we can use the same add_aggregated_privacy_manifest method and just not do aggregation to simplify the code somewhat.

Since this code path runs only if a user opts-out of the aggregation step, I'd keep it as simple as possible, do 1), and treat it as a "hey, we noticed you don't have a manifest and decided to opt-out of aggregation, here's a sample file you could use that we placed in your project root but didn't touch your actual ios project".

[philIip]

should we iterate through all of the targets instead? will there always be one target with a symbol_type of symbol?

[aleqsio]

Tbh I'm not sure, we could either only do it for the first target or do all the following steps for all matching targets, potentially creating multiple PrivacyInfo files and linking to each corresponding target.

@cipolleschi – do you think this check is enough?

[cipolleschi]

I think that creating a privacy manifest for each 'application' target is the most correct approach.
Users might have a single project for iOS, MacOS, VisionOS and AppleTV apps... and in some very weird cases, even multiple iOS apps in the same project, to share most code, like a monorepo setup.

I had to work in a similar scenario in the past, tbh. But I think it is an edge case for the React Native ecosystem.

[cipolleschi]

Left some comments, overall looks very good!
Many thanks for working on this!

[cipolleschi]

Suggested change

	app_delegate_path = target.source_build_phase.files_references.find { |file_ref| file_ref.name == "Info.plist" }
	info_plist_path = target.source_build_phase.files_references.find { |file_ref| file_ref.name == "Info.plist" }

[aleqsio]

I also changed it to read it from the user_project files, since info.plist does not end up in source_build_phase after all.

[cipolleschi]

I think that creating a privacy manifest for each 'application' target is the most correct approach.
Users might have a single project for iOS, MacOS, VisionOS and AppleTV apps... and in some very weird cases, even multiple iOS apps in the same project, to share most code, like a monorepo setup.

I had to work in a similar scenario in the past, tbh. But I think it is an edge case for the React Native ecosystem.

[aleqsio]

Now I'm looping over all application targets to add references – didn't really test it too much, but it seems pretty self-contained.

Generating the file and adding to one application target still works after recent changes

[facebook-github-bot]

@philIip has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[facebook-github-bot]

@philIip merged this pull request in 61f584c.

[github-actions]

This pull request was successfully merged by @aleqsio in 61f584c.

^{When will my fix make it into a release? | How to file a pick request?}

[liamjones]

@aleqsio I'm trying to backport this to 0.72 in advance of reactwg/react-native-releases#279 being done. I think this line might be naive/incorrect.

I believe I've integrated the changes into 0.72.14 correctly but when I try and pod install I get:

I've used pry to debug what's going on. It looks like the .first should be a .find (first only returns the first item in a collection) and, in my case .first is not a group, it's an xcconfig file:

Equivalent project structure view in Xcode:

While debugging, I also discovered that the groups have nil names, I think we want to match against path?

I've changed the line as follows:

file_root = user_project.root_object.main_group.children.find { |item| item.class == Xcodeproj::Project::Object::PBXGroup && item.path == target.name } || user_project

and it now integrates, finding the group name that matches my project name and adding the privacy manifest file to there.

[aleqsio]

You are absolutely correct, thanks for flagging 😍

The reason why it passed through my testing was that the privacymanifest file was the first in the array in rntester, AND the code block got swallowed without error – joys of ruby programming I guess.

[matinzd]

If a pod or multiple pods are deleted, shouldn't we make sure xcprivacy updates accordingly?

[liamjones]

@matinzd I think the problem there would be knowing what the user added to the root manifest themselves for their own code (and thus should remain) vs what was added only for a 3rd-party dependency (and thus should be removed).

The way we're handling it at our company is that we don't put our codes into the root manifest directly. We instead have a minimal app-specific cocoapod dependency which contains our reason codes and we blank the root manifest at the beginning of a pod install so that RN aggregates our manifest alongside the 3rd-party dependencies manifests.

[aleqsio]

@matinzd @liamjones Blanking the file is a good approach, or alternatively you can remove the privacy file manually when removing some pods – I assumed it's better to include more reasons than risk submit rejection, so this tool doesn't clear out entries from the privacy file by default.

I also considered marking entries or saving a shadow file to track removed reasons or a multitude of other approaches, but they all added complexity that seemed more problem that it's worth.