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.

[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 facebook/react-native@61f584c3afb79ba705be8b6372ff9b6c5599680e.

[github-actions[bot]]

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

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

[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.