Fix pod install for swift libs using new arch

[louiszawadzki]

Summary:

This fixes a bug that started with React Native 0.72.0 when using the new architecture and installing a native lib that has Swift code (in my case, @datadog/mobile-react-native).

Running pod install errors with the following output (DatadogSDKReactNative is the pod containing the Swift code):

[...]
Analyzing dependencies
Downloading dependencies
Installing DatadogSDKReactNative 1.8.0-rc0
[!] The following Swift pods cannot yet be integrated as static libraries:

The Swift pod `DatadogSDKReactNative` depends upon `React-Fabric`, `React-graphics`, `React-utils`, and `React-debug`, which do not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.

Indeed, this pods were added as dependencies in packages/react-native/scripts/cocoapods/new_architecture.rb but do not define modules contrary to the other pods in the list.

I've added :modular_headers => true for all these pods and this fixes the issue.

EDIT: after testing it, I added a few modular headers to a few more pods that have been added to the list of dependencies.

This PR is solving a problem that already occured in the past and was solved here: #33743

Changelog:

[IOS] [FIXED] - Fix pod install for libraries using Swift code when the new architecture is enabled

Test Plan:

1. Clone this repo
2. From main, add a Swift file to the MyNativeView native module in the RN tester app (see inspiration from this commit)
3. Try to run RCT_NEW_ARCH_ENABLED=1 USE_HERMES=0 bundle exec pod install inside the packages/rn-tester
4. Observe errors
5. Apply the commit from this PR
6. Both pod install and the subsequent build should succeed.
7. Revert the changes and repeat steps 2 to 6 with RCT_NEW_ARCH_ENABLED=1 USE_HERMES=1 bundle exec pod install

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	9,001,279	-2
android	hermes	armeabi-v7a	8,261,860	-2
android	hermes	x86	9,514,679	-2
android	hermes	x86_64	9,357,434	-2
android	jsc	arm64-v8a	9,560,255	-4
android	jsc	armeabi-v7a	8,698,149	-3
android	jsc	x86	9,644,526	+0
android	jsc	x86_64	9,891,374	+0

Base commit: 26ef0d5
Branch: main

[cipolleschi]

hi there, thanks for taking care of this!

Out of curiosity, instead of modifying these files (which is a totally valid approach!) have you tried setting the DEFINE_MODULES => YES (example) property in the podspecs of the failing pods?

If yes, how does it fails?
If not, could you try?

[facebook-github-bot]

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

[dmytrorykun]

@louiszawadzki could you please also test this fix with USE_HERMES=1, and add that to the test plan?

[louiszawadzki]

Hi @cipolleschi, thanks for the feedback, it works indeed with your suggested approach!
I've opened a new PR with this new implementation: #38121

[louiszawadzki]

@dmytrorykun will do, and will do so as well for the new PR I've opened :)

[cipolleschi]

Hi @louiszawadzki! are you ok in closing this as #38121 superseedes this with the right solution, imho?

[louiszawadzki]

@cipolleschi done :)

[louiszawadzki]

whoops closed the wrong one. Closing this one :)