Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36335
This change depends on [this PR](https://github.com/react-native-community/cli/pull/1849) of the CLI that introduces the `unstable_reactLegacyComponent` field in the `react-native.config.js` file.
This change introduce a JS script that reads that fields and generated a method in an object to return a list of components to be registered. The `RCTAppDelegate` has been updated to read those components and to automatically register them into the interop layer.
Notice that a user can just update the `react-native.config.js` and rebuild the app to integrate these changes, there is no need to reinstall the pods.
The idea behind this logic is to let the user know which components they are using with the interop layer, rather than rely on some black magic that could leave them blind to the need of actually migrate their apps.
## Changelog:
[iOS][Changed] - Implement mechanism to register legacy components in the iOS Fabric interop layer
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43665973
fbshipit-source-id: b4e8d71fa1bbed7a6130ee4f83a6221394d5306e
Summary:
The previous fix for -DNDEBUG required to install the pods with PRODUCTION=1 in order to add the flag. The flag was added also to Debug configurations, which is not ideal.
With this change, we remove the requirement of running `PRODUCTION=1 pod install` and we install the -DNDEBUG flag to all the release configurations.
## Changelog:
[iOS][Changed] - Install the -DNDEBUG flag on Release configurations, without requiring PRODUCTION=1 flag
Reviewed By: cortinico
Differential Revision: D43535620
fbshipit-source-id: af97bef06f267dddd5ce13a466bbc8d9a5eb2b0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36209
ThisChange automatically enable the RuntimeScheduler when the new architecture is enabled, both on RNester and in the Template app.
Note that no migration steps are required.
## Changelog
[iOS][Changed] - Automatically install the RuntimeScheduler
Reviewed By: sammy-SC
Differential Revision: D43392059
fbshipit-source-id: 609ded9bdc3db13a0d54ff44d0d4687dfc8617a5
Summary:
By leveraging the `PUBLIC_HEADERS_FOLDER_PATH` build settings of Xcode, we can instruct cocoapods to generate the frameworks Headers in a specific folder, for example the `React` folder.
This allows us to maintain the `#include`/`#import` structure, even if the framework has a different name.
However, we need to update the search paths to take into account this extra folder.
## Changelog:
[iOS][Changed] - Generate RCTFabric framework's headers in the React folder
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43425677
fbshipit-source-id: 94a4f3a3c7de86341b3ce3457704e6b8fb9a588e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36210
One of the circular dependencies we have in OSS was between React-Codegen and React-Fabric.
React-Codegen generates component which has to depends on React-Fabric because they need to use the files contained in the `react/renderer/view` folder.
React-Fabric contains some components that depends on RNCore, which was generated inside the React-Codegen folder.
This change generates the RNCore components inside the `ReactCommon/react/renderer/components/rncore` folder, breaking the dependency as `rncore` folder is now contained by React-Fabric itself.
**Fun Fact:** That's how it always should have been. There was already a line in the `.gitignore` to exclude the content of `ReactCommon/react/renderer/components/rncore` folder. I guess that with some of the refactoring/previous projects on Codegen, this requirements has slipped.
## Changelog:
[iOS][Breaking] - generates RNCore components inside the ReactCommon folder and create a new pod for platform-specific ImageManager classes
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43304641
fbshipit-source-id: ebb5033ce73dbcd03f880c3e204511fdce04b816
Summary:
This diff update the Cocoapods scripts to install the proper dependencies and search paths when `use_frameworks!` is declared together with the New Architecture.
Practically, it adds the right search paths to the codegen and the project files and makes sure that third party dependencies that leverage the `install_modules_dependencies` are populated with the right search paths for Frameworks.
It also adds unit tests for the changes and the new methods introduced.
## Changelog:
[iOS][Changed] - Properly install dependencies with `use_frameworks!`
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089869
fbshipit-source-id: 1981b6853f774fdb3dbe8d17ea37fd5154c54b25
Summary:
Fixes https://github.com/facebook/react-native/issues/36097
When building RNTester with the old architecture, we skip a call to `build_codegen`, which will build the JS package at `packages/react-native-codegen`. This is needed for the Xcode Script phase `Generate Specs`. This causes a build with fabric disabled to fail. We can fix this by ensuring we call `build_codegen` in both paper and fabric.
We've had this change in React Native macOS already since 0.68: https://github.com/microsoft/react-native-macos/commit/1175372ffecf6b4e18fa27b75b68f3ec7967a384
## Changelog
[IOS] [FIXED] - Build codegen package while using old architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/36098
Test Plan:
CI should suffice. Locally built RN-Tester without fabric with and without my change to show that disabling fabric will only succeed with this change included.
While running `pod install`, you should now see this extra line with the old architecture:
> [Codegen] building ./../../packages/react-native-codegen.
Reviewed By: cortinico
Differential Revision: D43152692
Pulled By: cipolleschi
fbshipit-source-id: 2cf3002f07eaad442ccb0272831fe2de58ec9c1a
Summary:
The variable `version` is previously used but in https://github.com/facebook/react-native/commit/234486068e7f547450829d17e8d5db111a1571bc#diff-adcf572f001c2b710d14f409c14763f1a50b08369b3034548f1602685d21f67f, its usage have been removed the but the variable is kept.
It also raises an error when using `bundle exec pod install --project-directory=ios` which works on `0.70.X` and below.
```txt
No such file or directory @ rb_sysopen - ../node_modules/react-native/package.json
/Users/davidangulo/Desktop/mobile/myapp/node_modules/react-native/scripts/react_native_pods.rb:212:in `read'
/Users/davidangulo/Desktop/mobile/myapp/node_modules/react-native/scripts/react_native_pods.rb:212:in `react_native_post_install'
```
## Changelog
[IOS] [FIXED] - pod install with --project-directory
Pull Request resolved: https://github.com/facebook/react-native/pull/35754
Test Plan: `bundle exec pod install --project-directory=ios` should not raise an error.
Reviewed By: christophpurrer
Differential Revision: D42298517
Pulled By: rshest
fbshipit-source-id: bef0b03312d2029188ae5437e3baf3ffce5cb73f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35679
The Codegen cleanup step was not always working due to an issue with the codegen folder path. It was working for RNTester, but not for apps created from the Template.
## Changelog:
[iOS][Fixed] - Fix path issue to properly run the codegen cleanup step
Reviewed By: jacdebug
Differential Revision: D42137600
fbshipit-source-id: ba4cb03d4c6eb17fda70a4aff383908d2e468429
Summary:
This PR introduce an automatic way to detect whether the user sets its podfile to use frameworks.
In this way, users don't have to install pods with a specific environment flag but they can rely on the standard Cocoapods usage
## Changelog
[IOS][ADDED] - Automatically detect whether use_frameworks! is used
Pull Request resolved: https://github.com/facebook/react-native/pull/35636
Test Plan:
- CircleCI is Green
- Added unit tests
- Tested locally with an app
Reviewed By: dmytrorykun
Differential Revision: D42029355
Pulled By: cipolleschi
fbshipit-source-id: 76c92133deabbda59603b043a4d542737f10f044
Summary:
This diff adds prepare command to hermes-engine.podspec. That command creates dummy `universal/hermes.xcframework` and `maocosx/hermes.framework`. This allow us to utilise CocoaPods auto-linking, and remove manual linking/cleanup code.
Also we now do not pollute user project with "Copy Hermes Framework" script phase. Which was quite bad on its own, and also caused annoying bugs on the CI.
allow-large-files
Changelog:
[iOS][Changed] - Prepare dummy hermes.xcframework before pod install.
Reviewed By: cipolleschi
Differential Revision: D41533994
fbshipit-source-id: d7d098ba5e882ac2d036335c23d7cda447d75b8d
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This brings back JSIDynamic and JSI together because the current setup is not compatible with iOS frameworks
## Changelog
[iOS][Added] - Bring back JSIDynamic and JSI
Reviewed By: cortinico
Differential Revision: D41557823
fbshipit-source-id: 95eb2fe7df69992861396e41d11cd5182193e1a3
Summary:
This PR backports the changes in 0.71 to apply the same logic to decide when we have to build Hermes from source in both the `hermes-engine.podspec`
and in the `react_native_pods.rb` script.
## Changelog
[iOS] [Fixed] - Use the right logic to decide when we have to build from source
Pull Request resolved: https://github.com/facebook/react-native/pull/35469
Test Plan: Working on RC2
Reviewed By: cortinico
Differential Revision: D41529539
Pulled By: cipolleschi
fbshipit-source-id: 879522c2187df28f40f6bc699057e9ecfb7e25fb
Summary:
Build hermesc in Xcode run script phase, so it ends up inside `Pods/hermes-engine/buld_host_hermesc`. All the the housekeeping is now done by CocoaPods and Xcode, and we can get rid of all the setup/cleanup code.
Changelog:
[iOS][Changed] - Build hermesc in Xcode run script phase.
Reviewed By: cipolleschi
Differential Revision: D41521987
fbshipit-source-id: 336854fa23582255cba6d161acf2cc791cac9d00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35397
This Diff removes the `HERMES_BUILD_FROM_SOURCE` that was not always propagated to the original script. This lead to some cases where hermesC was built during `pod install` and then removed by the `react_native_post_install`'s `else` branch.
Basically, when the Pods are installed the first time, everything run smoothly. Subsequent invocations of `pod install`, to install other dependencies, for example, will incur in this problem because:
1. Cocoapods will see that hermes-engine is already installed
2. the podspec is not executed, given that the pod has been fetched from the cache
3. The env var is not set (given that the podspec is not executed)
4. the main script sees the env var as not set, `ENV['HERMES_BUILD_FROM_SOURCE'] == "1"` return false
5. The `else` branch is executed, and it removes the `hermesc_build_dir` and the `copy Hermes framework` script phase.
## Changelog:
[iOS][Changed] - Remove `HERMES_BUILD_FROM_SOURCE` flag
Reviewed By: cortinico, dmytrorykun
Differential Revision: D41373439
fbshipit-source-id: ea4aafd187c0ca3ff5c0d79f8aeaaa46ad50f499
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
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/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:
The React-Hermes and hermes-engine headers are only needed when Hermes is enabled.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40451162
fbshipit-source-id: d38830f8abe57a91798e216d7930bb7add483899
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:
The jsi library itself is `jsi/jsi.{h,cpp}`. JSIDynamic provides support for converting between folly::dynamic and jsi::value, independent of the jsi library.
Changelog:
[iOS][Changed] Moved JSIDynamic out of React-jsi and into React-jsidynamic
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40334023
fbshipit-source-id: d2c69e7afb7f43f93080301b88c81e1fa46279d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34754
This Diff is the second step of enabling the CodeGen to parse and generate a NativeState for the components.
The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.
## Changelog
[General][Added] - Always generate an empty NativeState for Fabric Components
Reviewed By: cortinico
Differential Revision: D39696435
fbshipit-source-id: e24768af78f59696c0b4db009e8065bb5c89316b
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/34670
Users can enable the New Architecture on iOS in two way: using the `RCT_NEW_ACRH_ENABLED` env variable or setting the `new_arch_enabled` flag when invoking the `use_react_native` function.
We need to set the `RCT_NEW_ACRH_ENABLED` even when the other method is used because we need to inject that flag into the codebase.
## Changelog
[iOS][Fixed] Make sure to turn on the `RCT_NEW_ACRH_ENABLED` flag
Reviewed By: cortinico
Differential Revision: D39430904
fbshipit-source-id: abb55642b4c72d7dec8b045fb4a43c1763f0ee0f
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:
This PR is the dual of the Matrix Tests we added to the Android Template a couple of weeks ago. It adds the same tests to iOS, to verify that the template builds with both architectures and with both configurations (Debug/Release).. And it tests that the template works with both Hermes and without it.
## Changelog
[iOS] [Added] - Test iOS template with both architectures and configurations
Pull Request resolved: https://github.com/facebook/react-native/pull/34469
Test Plan: CI is green in all the 8 new jobs.
Reviewed By: hramos, cortinico
Differential Revision: D39087876
Pulled By: cipolleschi
fbshipit-source-id: 1205b2339bac87cf11b4f356a2e50e1e93ba52bc
Summary:
The `sed` workaround here in `__apply_Xcode_12_5_M1_post_install_workaround`:
https://github.com/facebook/react-native/blob/main/scripts/react_native_pods.rb#L293-L298
does not work when the react native project has a parent folder with a space in the the name, for example:
`/Users/myuser/Some Folder/my-project/ios/Pods/RCT-Folly/folly/portability/Time.h`
This is because the `sed` command thinks that the part after the space is a separate argument.
This bug caused one of our engineers to not be able to run our React Native project through no fault of his own, so I would like to propose this change to help other engineers avoid this in the future.
## Changelog
Add single quotes around the file parameter in the `sed` command
[iOS] [Fixed] - Fixed Time.h:52:17: error when a folder in the file path has a space
Pull Request resolved: https://github.com/facebook/react-native/pull/34510
Test Plan:
Checkout the main branch.
Create a React Native project in a folder that has a space in the name.
When you run `pod install`, you should notice a `sed` error indicating that the text replacement failed.
Run the build to reproduce the `Time.h:52:17: error`.
Checkout this branch.
Run `pod install` and notice the `sed` error is gone.
Run the build, the error should be gone.
Reviewed By: sammy-SC
Differential Revision: D39082262
Pulled By: cipolleschi
fbshipit-source-id: 211099234edc6c9ee959bb61a760a6ca04a7a301
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34440
While testing some recent changes on a nightly, I realized that if we install the dependencies using RCT_NEW_ARCH_ENABLED=1 and we forget to change the flag in the Podfile, Fabric dependencies won't be installed.
However, Fabric is required by the New Architecture. This fix makes sure that we install Fabric dependencies when the New Architecture is enabled.
## Changelog
[iOS][Changed] Install Fabric dependencies when RCT_NEW_ARCH_ENABLED=1
Reviewed By: cortinico
Differential Revision: D38786978
fbshipit-source-id: 664151de0250577a19af949f8850e5efa8a13373
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34384
This Diff aims to create a RCTAppDelegate library to offer a subclass which automates some operations required to set up the new architecture.
## Changelog
[iOS][Added] - Added the RCTAppDelegate library
Reviewed By: cortinico
Differential Revision: D38580424
fbshipit-source-id: 38f6c4b8ff2790a2ce9e23d385b36307701cffb7
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:
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/34177
This Diff destructures the parameters of the use_react_native! function. It does that in a backward compatible way, so we there should be no disruptions.
It also adds documentation to the various public method we want to export to our users.
## Changelog
[iOS][Changed] - Destruct use_reactnative parameters and ad ddocumentation
Reviewed By: cortinico
Differential Revision: D37787365
fbshipit-source-id: 27f9030db2e8c6c66b9548b4c1287eb8165ae5fc
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/34142
The `||=` operator in an expression like `x = a ||= b` works in a way that:
- if a is null, it assigns b to x
- if a is `falsy`, it assigns b to x
- otherwise, it assigns a to x.
In our setup, if the user set `hermes_enabled` to `false` in the Podfile (one of the suggested way to disabled Hermes), the `options[:hermes_enabled]` part will evaluate to false and, therefore, `hermes_enabled` will obtain the value of `true`.
## Changelog
[iOS][Changed] - Use the correct operator to decide whether Hermes is enabled or not.
Reviewed By: cortinico
Differential Revision: D37643845
fbshipit-source-id: 387f7bd642250c40873400d22d7d85451462c073
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:
Bumping RTC-Folly version used to address CVE-2022-24440.
## 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][Security] - Bump RTC-Folly to 2021-07-22
Pull Request resolved: https://github.com/facebook/react-native/pull/33841
Reviewed By: Andjeliko, philIip
Differential Revision: D36425598
Pulled By: cortinico
fbshipit-source-id: d38c5f020dbecf794b10f12ed2da30e1825071af
Summary:
`use_frameworks!` is broken again in react-native 0.69 because React-bridging. in the `use_frameworks!` mode, header structures are flattened, so `#include <react/bridging/CallbackWrapper.h>` is not reachable to the header. to somehow workaround the issue without touch React-bridging imports, the pr do these things:
- use `header_mappings_dir` to keep `react/bridging` header structure
- because the header structure is not default framework header structure, explicitly `HEADER_SEARCH_PATHS` is necessary.
- forward declare `CallbackWrapper` and use it internally in ReactCommon. so that we don't need to add `HEADER_SEARCH_PATHS` for React-bridging to every pods depending on `ReactCommon/turbomodule/core`, e.g. React-RCTSettings.podspec.
## Changelog
[iOS] [Fixed] - Fix use_frameworks! for 0.69
Pull Request resolved: https://github.com/facebook/react-native/pull/34011
Test Plan:
```sh
$ npx react-native init RN069 --version next
# add `use_frameworks!` to ios/Podsfile
# comment out use_flipper!() in ios/Podfile
# patch node_modules/react-native with these changes
$ yarn ios
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D37169699
Pulled By: dmitryrykun
fbshipit-source-id: 309c55f1c611a2fc3902a83e8af814daaf2af6a0
Riccardo Cipolleschi
Saad Najmi
David Angulo
Riccardo Cipolleschi
Dmitry Rykun
Christoph Purrer
Donald Webster
Paige Sun
Héctor Ramos
Lorenzo Sciandra
Gabriel Rogan
Kudo Chien
LeoTM
Arkkeeper
Héctor Ramos
Luis Santana