Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35212
A previous change - https://github.com/facebook/react-native/pull/34011 - already fixed basic usage of <react/bridging/.../ imports.
However that change was only tailored towards the usage of: <react/bridging/CallbackWrapper.h>
Any other header besides <react/bridging/CallbackWrapper.h> from <react/bridging/... can't be imported at this time in Xcode ... ... which is bad.
For C++ TurboModules we need to be able to access *any* <react/bridging/...> header via the React-Codegen CocoaPod.
Hence adding bridging now as a sub-spec to the ReactCommon CocoaPod
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41057878
fbshipit-source-id: 83c117bc5252d84dd419cdb72f145f65547d23b2
# Conflicts:
# scripts/cocoapods/__tests__/codegen_utils-test.rb
Summary:
## Context
If React Native is built from *main* of any non-stable commit, then Hermes is built from source. The build is performed by `build-ios-framework.sh` and `build-mac-framework.sh` scripts in `hermes-engine.podspec` `prepare_command` stage. Since those scripts have no access build target information, they build all possible architectures and platforms just in case. That takes ages.
## Solution
The idea is to integrate build script into Xcode *run script* phase, and use build target information to build Hermes for active architecture only.
## Implementation
- Existing behaviour remains unchanged for local tarball and remote prebuild cases.
- `build-hermesc-xcode.sh` builds Hermesc as `hermes-engine.podspec` `prepare_command`. Default build location is `react-native/sdks/hermes-engine/build_host_hermesc`.
- `build-hermes-xcode.sh` builds Hermes in 'Build Hermes' Xcode script phase. It uses `$PLATFORM_NAME`, `$CONFIGURATION`, `$ARCHS`, `$IPHONEOS_DEPLOYMENT_TARGET` and `$MACOSX_DEPLOYMENT_TARGET` environment variables to configure cmake project so it builds only active architecture. The script also gets RN version, *cmake* path and *hermesc* path from the podspec.
- `copy-hermes-xcode.sh` copies Hermes.framework inside the app bundle. This script phase is added to the user app target in a `post_install` hook, after pods are integrated in a user project.
- `OTHER_LDFLAGS -framework "hermes"` added to the user project to enable linking against Hermes.framework.
- If `HERMES_OVERRIDE_HERMESC_PATH` is set, then Hermesc building is skipped, and `HERMES_OVERRIDE_HERMESC_PATH` is used for `build-hermes-xcode.sh`.
- `HERMES_CLI_PATH` is injected into user project config to enable Hermes source maps in `react-native-xcode.sh`.
## Things that didn't work
- *Running build-hermesc-xcode.sh in Xcode run script phase*. This doesn't work because Hermesc is supposed to be built for macos, and if build target is ios, then Xcode configures environment in such a way that Hermesc build fails.
- *Installing Hermesc into CocoaPods download folder*. So it then ends up in `Pods/hermes-engine/build_host_hermesc`, and all the housekeeping is handled by CocoaPods. This doesn't work because cmake uses absolute paths in a configured project. If configured project is moved to a different location, nothing builds.
- *Installing Hermesc directly into Pods/hermes-engine*. This doesn't work because CocoaPods runs prepare_command before Pods folder clean up, and everything gets wiped.
## Known issue
- If `Pods/hermes-engine` is manually removed, then `sdks/hermes-engine/build_host_hermesc` must also be removed before running `pod install`. Otherwise cmake will complain about stale cache:
```
CMake Error: The source "<CocoaPodsCache>/hermes-engine/<hash2>/CMakeLists.txt" does not match the source
"<CocoaPodsCache>/hermes-engine/<has1>/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
```
## Benchmark
MacBook M1 2021 32 GB.
```
export REACT_NATIVE_PATH=~/fbsource/xplat/js/react-native-github
cd $REACT_NATIVE_PATH/packages/rn-tester
pod install
rm -rf $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
echo 't1=$(date +%s); $@; t2=$(date +%s); diff=$(echo "$t2 - $t1" | bc); echo Operation took $diff seconds.' > /tmp/benchmark.sh
```
```
# Before
export BUILD_TYPE=Debug
export JSI_PATH=$REACT_NATIVE_PATH/ReactCommon/jsi
export RELEASE_VERSION=1000.0
export IOS_DEPLOYMENT_TARGET=iphonesimulator
export MAC_DEPLOYMENT_TARGET=12.6
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-ios-framework.sh
# Operation took 252 seconds
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-mac-framework.sh
# Operation took 179 seconds
```
```
# After
. /tmp/benchmark.sh source $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-hermesc-xcode.sh $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
# Operation took 59 seconds.
. /tmp/benchmark.sh xcodebuild -workspace $REACT_NATIVE_PATH/packages/rn-tester/RNTesterPods.xcworkspace -scheme hermes-engine
# Operation took 106 seconds.
```
|Before|||After|||
|--|
|iOS framework (s)|Mac framework (s)|Total (s)|Hermesc (s)|Target-specific framework (s)|Total (s)|
|252|179|431|59|106|**165 (-266) (-61%)**|
The performance win is fixed, and does not depend on the project size and structure.
As an example, this is how these changes affect build time of RNTester.
|Before||||After|||
|--|
||Pod install (s)|Xcode build (s)|Total (s)|Pod install (s)|Xcode build (s)|Total (s)|
|Clean build|1219|132|1352|734 (-485)|249(+117)|**983 (-369)**|
|Incremental build|82|30|112|105 (+23)|**34 (+4)**|139 (+27)|
The most important values here are the total clean build time and the incremental Xcode build time. The first one went down by 369 seconds, the second one went up by 4 seconds. I consider it a reasonable tradeoff.
The extra 4 seconds in the incremental Xcode build time can potentially be mitigated by setting up output file lists for the new script phases.
allow-large-files
Changelog:
[iOS][Changed] - Hermes is integrated into Xcode build.
Reviewed By: hramos
Differential Revision: D40063686
fbshipit-source-id: e6993d62225789377db769244bc07786cc978a27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35160
With the simplified migration to the new arch, we are offering a function in cocoapods that takes care of configuring all the dependencies for libraries.
That function was not setting the proper version of C++ for the library. This could lead to build problems.
This Diff make sure that the libraries that are created with this function call have the proper C++ version.
NOTE: we already have a post install hook that was setting the the proper C++ version, but that was only working for the project. Plus, we can't read that version from the React-Core podspec because at the podspec definition time, cocoapods has not read that yet. Therefore, I just hardcoded the C++ version on top of the file, so it will be easier to update if we decide to change it.
## Changelog
[iOS][Fixed] - Make sure that libraries created with `install_modules_dependencies` has the right C++ version.
Reviewed By: dmytrorykun
Differential Revision: D40894561
fbshipit-source-id: a5187be2d85888a335d4c033f16fdacaf2c945f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35038
React-jsi provides JSI to allow React Native to interface with JavaScriptCore.
The hermes-engine Pod provides a second copy of JSI, as Hermes is built and linked statically with JSI.
This second copy of JSI would lead to an [ODR Violation](https://en.cppreference.com/w/cpp/language/definition).
To resolve this, when Hermes is enabled:
- React-hermes and hermes-engine are installed.
- React-jsc is not installed.
- React-jsi continues to be installed.
- React-jsi will not build JSI.
- React-jsi will declare a dependency on hermes-engine.
The result is that the JSI dependency for React Native is satisfied by hermes-engine, and there is no duplicate JSI library in the project.
When Hermes is disabled:
- React-jsi and React-jsc are installed.
- React-hermes and hermes-engine are not installed.
- React-jsi will build JSI.
Changelog:
[iOS][Changed] Resolve JSI ODR violation, make hermes-engine the JSI provider when Hermes is enabled
Reviewed By: cipolleschi
Differential Revision: D40334913
fbshipit-source-id: 409407a193a35cbd21b0e8778537b3627e4c54a2
Summary:
Move JSC and Hermes CocoaPods configuration to scripts/cocoapods/jsengine.rb.
This file provides a setup_jsc! function and a setup_hermes! function that will configure the necessary pod dependencies for each of the supported JavaScript engines.
Currently, the JSI and JSC pods are installed in both cases. This will likely change in upcoming changes to how Hermes and JSC are configured.
Changelog: [internal]
Reviewed By: dmytrorykun
Differential Revision: D40459234
fbshipit-source-id: d6c89c7f650b1efcce5622594db7fd726eafc2bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35031
The React-jsi Pod was serving two purposes: building JSI, and configuring JavaScriptCore as the JS engine.
By splitting the React-jsi Pod into React-jsi and React-jsi, we can start working towards de-coupling the JSI dependency from any particular JS engine.
Pods that depended on React-jsi, now depend on React-jsi and React-jsc.
One exception to this is React-hermes, which is only installed when Hermes is enabled, and thus does not require JavaScriptCore.
Upcoming commits should take care of removing the React-jsc dependency when Hermes is enabled, but it is out of scope for this commit.
Changelog:
[iOS][Changed] - The JSC Runtime is now provided by the React-jsc Pod instead of React-jsi. Libraries that declared a dependency on React-jsi in order to specifically create a JSC runtime (`makeJSCRuntime()`) will need to add React-jsc to their dependencies.
Reviewed By: dmytrorykun
Differential Revision: D40442603
fbshipit-source-id: b9b21146b9deb401f80cfef76a87c9867754a953
Summary:
This is a long time coming effort to improve the situation around the local e2e script that in the release crew: the current bash-based script is quirky at best, and what you end up generating as a sample project is not really a true sample project. This is where this PR comes in: it migrates the flow from `./scripts/test-manual-e2e.sh` to `yarn test-e2e-local <options>`.
Here's the current shape of the options:
```sh
Options:
--help Show help [boolean]
--version Show version number [boolean]
-t, --target [choices: "RNTester", "RNTestProject"] [default: "RNTester"]
-p, --platform [choices: "iOS", "Android"] [default: "iOS"]
-h, --hermes [boolean] [default: true]
```
The idea is to change it so that you can just run the script, and it will do that one specific thing "well", without the tester needing to do anything aside from actually testing the app once it's open.
Some of the key changes:
* tries to stick to the patterns of the other established *.js based scripts, in terms of tooling and approach (and even refactor parts that can be shared with other scripts) - like the android artifacts generation
* no need to start the android emulator on the side
* no need to start Metro on the side
* RNTester iOS will open up on the simulator (no Xcode open that then you need to press)
Things that still need work:
* see the #fixme and #todo in comments
* because we rely on exec, the output sent back is not formatted/shaped correctly so it's a bit more noisy/chaotic - but can't handle it right now because the package we use doesn't allow it - see https://github.com/shelljs/shelljs/issues/86
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Migrate bash E2E local testing script to new JS based command
Pull Request resolved: https://github.com/facebook/react-native/pull/34513
Test Plan:
To test the script, you can run it passing the options showed above; this is the current situation:
* RNTester iOS Hermes ✅
* RNTester Android Hermes ✅
* RNTester iOS JSC ✅
* RNTester Android JSC ✅
* RNTestProject Android Hermes ✅
* RNTestProject iOS Hermes ✅
* RNTestProject Android JSC ✅
* RNTestProject iOS JSC ✅
Reviewed By: cortinico
Differential Revision: D39814692
Pulled By: cortinico
fbshipit-source-id: d4791798aaad764c6a3757269b7636f847ccf2ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34776
CocoaPods is not used when Hermes is built in Circle CI, so we cannot rely on the React Native CocoaPods scripts to be loaded.
The get_hermes_build_type function is removed from the RN CocoaPods scripts and in its place, the ENV['PRODUCTION'] envvar is accessed directly.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D39778190
fbshipit-source-id: 12083b7b4533b4ad7bb7a08612883983a0583616
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34761
Separate debug and release tarballs are built in CI. Use the appropriate Hermes artifacts tarball when building hermes-engine.
Add hermes.rb tests.
Changelog:
[iOS] [Changed] - Remove debugger from Hermes when building for release
Reviewed By: cipolleschi
Differential Revision: D39698499
fbshipit-source-id: e6b10d34c7f94c2f86fc47d8b97466011aaa75cc
Summary:
This Diff adds a couple of APIs to the `react_native_pods.rb` file to simplify further the migration to the New Architecture for the iOS app.
Specifically, it aims to simplify [this](https://reactnative.dev/docs/next/new-architecture-app-intro#ios---build-the-project) steps by offering a RN-managed min version and creating the .xcode.env file for the user if it is missing.
## Changelog
[iOS][Added] - Add new API to simplify app migration
Reviewed By: cortinico
Differential Revision: D39469599
fbshipit-source-id: f0323e86c83c2731671fcd5bb4288071304bb43b
Summary:
Fix invalid range "t-5" in string transliteration [iOS] for M1 pod install issue.
This should fix pod install error for M1 machines.
## Changelog
[iOS] [Fixed] - Fix ios pod install error
Pull Request resolved: https://github.com/facebook/react-native/pull/34636
Test Plan: Run pod install on M1 machine.
Reviewed By: sammy-SC
Differential Revision: D39423276
Pulled By: cipolleschi
fbshipit-source-id: 4ec95af7103395792facba0f93fd8de05a3fe78d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34619
When it comes to migrate existing libraries, users needs to update their .podspec files with a bunch [of changes](https://reactnative.dev/docs/0.69/new-architecture-library-ios#add-folly-and-other-dependencies).
This diff groups those changes in a single function, so that contributors can just invoke that function to prepare their dependencies.
## Changelog
[iOS][Changed] - Add function to simplify podspecs
Reviewed By: cortinico
Differential Revision: D39312203
fbshipit-source-id: ed631839e07d472a1fdcba33310f9b1d94fe2fd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34398
This Diff cleans up the codegen folder for iOS when we install the pods. This is useful to start from a clean situation. The codegen runs after this step and we make sure that the file system is clean
## Changelog
[iOS][Changed] - Cleanup codegen build folder before installing the pods
Reviewed By: cortinico
Differential Revision: D38657027
fbshipit-source-id: 8a914457d7963521d6d8dc7819eba864736f50a0
Summary:
Fixed Flipper not recognizing app when using custom Xcode configuration names.
This fixes the problem that renaming the "Debug" Xcode configuration causes Flipper to not work. Despite using the recommended `:configurations` parameters and instructing Cocoapods that it was a debug build (see https://github.com/facebook/react-native/issues/34332), it still wouldn't recognize the app due to missing C preprocessor flags, specifically it was missing `-DFB_SONARKIT_ENABLED=1`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Flipper now supports custom Xcode build configuration names
Pull Request resolved: https://github.com/facebook/react-native/pull/34333
Test Plan:
I applied the PR change to 0.68.2 (which work similarly but code was refactored since then). I then used `patch-package` to test the change and the fix worked on 2 separate projects.
Patch-package change equivalent:
```diff
diff --git a/node_modules/react-native/scripts/react_native_pods.rb b/node_modules/react-native/scripts/react_native_pods.rb
index f2ceeda..2ea57d6 100644
--- a/node_modules/react-native/scripts/react_native_pods.rb
+++ b/node_modules/react-native/scripts/react_native_pods.rb
@@ -180,7 +180,7 @@ def flipper_post_install(installer)
# Enable flipper for React-Core Debug configuration
if target.name == 'React-Core'
target.build_configurations.each do |config|
- if config.name == 'Debug'
+ if config.debug?
config.build_settings['OTHER_CFLAGS'] = "$(inherited) -DFB_SONARKIT_ENABLED=1"
end
end
```
**Screen shot of Xcode after the patch has been applied, for RN v0.68.2:**

Reviewed By: dmitryrykun
Differential Revision: D38373812
Pulled By: cipolleschi
fbshipit-source-id: d2949927084160bf0c6f8af37a7966dd22fea9a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34368
When a user runs `RCT_NEW_ARCH_ENABLED=1 pod install` to install the dependencies for the New Architecture, Cocoapods prints a warning because of React Native is still set up with a legacy configuration.
This diff silences these warnings because they can confuse the final user.
**Note:** We need to keep this legacy configuration to support both the legacy and the New Architecture.
## Changelog
[iOS][Changed] - Silence warning due to react-native internal details.
Reviewed By: cortinico
Differential Revision: D38503405
fbshipit-source-id: b89857aa88435b1c64da52875606003239ff2e05
Summary:
cherry-pick changes from https://github.com/facebook/react-native/issues/34214 to main. because the `react_native_pods.rb` on main is quite different from 0.69, i have separated pr for the change.
## Changelog
[iOS] [Fixed] - Fix React-bridging headers import not found
Pull Request resolved: https://github.com/facebook/react-native/pull/34271
Test Plan: RNTester + pod install and verify pod targets to have `React-bridging` in header search paths.
Reviewed By: cipolleschi
Differential Revision: D38122074
Pulled By: dmitryrykun
fbshipit-source-id: 64569abbfa3a684f0d6b84c9e3222bfc9a171061
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34176
It extracts the code related to the codegen from the main `react_native_pods` script to a dedicated file, adding also tests.
## Changelog
[iOS][Changed] - Move codegen in separate files
Reviewed By: cortinico
Differential Revision: D37755818
fbshipit-source-id: 99760d1def26ddbf065fdd234e0d183c2795513c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34100
This Diff continue the effort of refactor and test the cocoapods script, moving hermes setup in a dedicated `hermes.rb` file and adding some tests on the logic of the hermes handling.
## Changelog
[iOS][Changed] - move and test Hermes setup from react_native_pods script into a dedicated file
Reviewed By: cortinico
Differential Revision: D37522432
fbshipit-source-id: 91112476aac576a30110e5dcd4e46fa12241962a
Summary:
This PR adds a new method called **__apply_mac_catalyst_patches** to **scripts/react_native_pods.rb**. If it is enabled in the Podfile, it will apply three patches necessary for successful building not only for iOS and tvOS targets, but also for macOS using Apple's Mac Catalyst technology.
These 3 patches are:
- Fixing bundle signing issues by altering CODE_SIGN_IDENTITY
- Explicitly setting dead code stripping flag in project.pbxproj
- Modifying library search paths
The details were discussed here https://github.com/reactwg/react-native-releases/discussions/21#discussioncomment-2754289
## Changelog
[iOS] [Added] - Add Mac Catalyst compatibility (can be enabled in Podfile)
Pull Request resolved: https://github.com/facebook/react-native/pull/34026
Test Plan:
1. Go to project settings in Xcode, to General tab. Enable "iPad" and "Mac Catalyst" checkboxes
2. Go to "Signing & Capabilities" tab, ensure that a correct bundle id and development team are set
3. Edit Podfile, uncomment **__apply_mac_catalyst_patches(installer)** line
4. Run `pod install` in ios directory
5. Get back to Xcode, select "My Mac (Mac Catalyst)" as a target device
6. Build & run
Reviewed By: cipolleschi
Differential Revision: D37362054
Pulled By: cortinico
fbshipit-source-id: 74636f716f112289ab40968bbc8e52406c1e9579
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34085
Hermes is now the default engine on iOS.
Apps can choose to continue using JSC by setting `hermes_enabled` to `false` in their Podfile.
The RNTester app now uses Hermes, as well. Use JSC in RNTester by setting `USE_HERMES=0` when running `pod install`.
Changelog:
[iOS][Changed] Hermes is now the default engine on iOS. This setting is controlled via `flags[:hermes_enabled]` in the Podfile.
Reviewed By: cortinico, cipolleschi
Differential Revision: D37361468
fbshipit-source-id: e6dda6a23eea4a824ad157d1a26f17e181db33cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34025
This diff moves the monkeypatch LocalPodspecPatch to a dedicated ruby file.
It also adds test for that
## Changelog
[iOS][Changed] - Move LocalPodspecPatch to dedicated file
Reviewed By: cortinico
Differential Revision: D37069361
fbshipit-source-id: 28fddb197484f45aa20ccac516c874e79448e999
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33990
This diff moves the setting of some CPP flags from the main React native pods file to a dedicated file.
It also introduces some tests and it improves the Test Mocks we have
## Changelog
[iOS][Changed] - Move the `modify_flags_for_new_architecture` method to separate ruby file
Reviewed By: cortinico
Differential Revision: D37040927
fbshipit-source-id: 037ddaf123d01f3a2fd622b8a0cd10535da70b92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33982
This Diff moves another part of the utilities from the `react_native_pods` file to a specific `utils.rb` file.
It adds tests for these utils and improve our test mocks.
The goal is to simplify the `react_native_pods.rb` so it's easier to work with it.
I decided to split this diff in 2 because it was becoming quite big.
## Changelog
[iOS][Changed] - Refactoring part of the react_native_pods.rb script
Reviewed By: cortinico
Differential Revision: D37006265
fbshipit-source-id: ffaac3270cb098fa30b73c97ce7cd350dfb8d7d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33978
This Diff moves part of the utilities from the `react_native_pods` file to a specific `utils.rb` file.
It adds tests for these utils and improve our test mocks.
The goal is to simplify the `react_native_pods.rb` so it's easier to work with it.
I decided to split this diff in 2 because it was becoming quite big.
## Changelog
[iOS][Changed] - Refactoring part of the react_native_pods.rb script
Reviewed By: cortinico
Differential Revision: D37004347
fbshipit-source-id: a5156f7c199d082d5d895a58af80948556c51c2a
Summary:
`OTHER_CFLAGS` doesn't seem to work when the file is imported from Objc++. This causes flipper to not be included.
## Changelog
[iOS] [Fixed] - Use `GCC_PREPROCESSOR_DEFINITIONS` to set `FB_SONARKIT_ENABLED`
Pull Request resolved: https://github.com/facebook/react-native/pull/33972
Test Plan: Tested the change in an app. Used a breakpoint to see that flipper code is not executed before this change, and is after. Also made sure other `GCC_PREPROCESSOR_DEFINITIONS` set by cocoapods are still properly inherited.
Reviewed By: cipolleschi
Differential Revision: D37001624
Pulled By: dmitryrykun
fbshipit-source-id: 920f3fe368a9fbe2cde9aa1e6d5b3b883c42119d
Summary:
This PR tries to simplify the `use_flipper` logic:
- makes `use_flipper` a configuration inside `use_react_native`'s options
- uses the already present `production` flag in the `use_react_native`'s options to decide if add or not the Flipper pods
- Simplifies the logic to download the flipper dependencies
This PR also adds a workaround for https://github.com/facebook/react-native/issues/33764
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Changed] - Move `use_flipper` logic inside `use_react_native` and simplify the Flipper dependencies logic
Pull Request resolved: https://github.com/facebook/react-native/pull/33882
Test Plan: Executed a pod install with and without flipper and with isProduction true
Reviewed By: cipolleschi
Differential Revision: D36592338
Pulled By: f-meloni
fbshipit-source-id: 3c3f773151513e27e251f18865986e942a96ffd9
Summary:
Currently this [section](https://reactnative.dev/docs/next/new-architecture-app-intro#ios-enable-c17-language-feature-support) of the Playbook tells us to set CLANG_CXX_LANGUAGE_STANDARD = "c++17" in the main app target for the new architecture to work.
Would be nice to be able to automate that instead
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Added] - Cocoapods function to add the `CLANG_CXX_LANGUAGE_STANDARD` to all the targets if needed
Pull Request resolved: https://github.com/facebook/react-native/pull/33863
Test Plan:
I've created some unit tests for the newly added function.
I've executed pod install and the ruby tests locally.
Reviewed By: cipolleschi
Differential Revision: D36484366
Pulled By: f-meloni
fbshipit-source-id: 553b092e747bef11d82195619ae1058985fdc325
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33818
This Diff moves the fabric setup from the `react_native_pods` script to its own `fabric` file.
It also introduces tests for the file and some test utilities.
## Changelog
[iOS][Changed] - Move fabric setup to its own file
Reviewed By: cortinico, dmitryrykun
Differential Revision: D36344911
fbshipit-source-id: 586186684be2c0080f247390f26145f2defa9e97
Summary:
Patch release bumps that just change arm64 slice packaging
See https://github.com/facebook/flipper/issues/3117#issuecomment-1123759397
These pods were just released by lblasa and this PR integrates them - I personally confirm success on an arm64 doing a macCatalyst build for the first time since react-native 0.64, and users report intel works fine as well - no regression
## Changelog
[Catalyst][Fix] - use pods with arm64 macCatalyst slices
Pull Request resolved: https://github.com/facebook/react-native/pull/33809
Test Plan:
Run a macCatalyst build on intel machine and m1 machine, I use this harness as part of release-testers facebook group, and it exercises macCatalyst build if you pass in a valid development team (for signing) https://github.com/mikehardy/rnfbdemo/blob/main/make-demo.sh
(the test harness is locally modified to no longer exclude M1 builds and with a patch-package that implements this PR, pending this merge+release...)
Reviewed By: cortinico
Differential Revision: D36339335
Pulled By: cipolleschi
fbshipit-source-id: d4574fc960e6ff345b31a83ff4629e22edfcf2f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33802
We use to have a couple of tests for the script phases script that were not running during the CI.
This diff connect them with the two CI, so that they run together with the other ruby tests.
## Changelog
[iOS][Added] - Run script phases tests in CI
Reviewed By: fkgozali
Differential Revision: D36283211
fbshipit-source-id: 01b257cdc99b0bc196d60d49ac76cf044d61a7e9
Summary:
This Diff moves all the Flipper.rb related setup in the cocoapods scripts to a dedicated script.
It also removes the not needed dummy files and add tests for flipper.
## Changelog
[iOS][Internal] - Extract Flipper setup in a separate file and add tests
Reviewed By: cortinico
Differential Revision: D36129808
fbshipit-source-id: 5446203a69b527146c893aa9611e98688e20b778
Summary:
This PR adds a step in the iOS legocastle script to run the ruby tests in the cocoapods folder.
These tests are executed before the pod installation step: this because we would like to fail as fast as possible in case of issues.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36006781
fbshipit-source-id: 8afbc1ccc751d2dc736bdc23ec382ebd7b5c7f4f
Summary:
This Diff prepares a set of dummy tests to make sure that our infra supports tests in ruby.
It also adds a scripts in the `__tests__` folder which can be invoked to run all the tests. The script performs a discovery of all the tests in the cocoapods folder.
Next steps will configure Sandcastles and CircleCI.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35968556
fbshipit-source-id: b8bf23d30dc5358ab603e396cce1c6639dd0f567