-
Notifications
You must be signed in to change notification settings - Fork 24.8k
Automate setting the RCTNewArchEnabled
flag
#49927
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This pull request was exported from Phabricator. Differential Revision: D70888212 |
Summary: This change automates updating App's Info.plist with the new `RCTNewArchEnabled` boolean entry. The value depends on how the pod install is set up. In this way, we maintain the previous UX to enable/disable the New Arch. ## Context The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not. However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example: - New Arch / Hermes - Old Arch / Hermes - New Arch / JSC - Old Arch / JSC - ... ## Backward compatibility We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself. ## Changelog: [iOS][Added] - Reviewed By: cortinico Differential Revision: D70888212
Summary: This change deprecates the RCT_NEW_ARCH_ENABLEd flag to toggle the New Architecture. The new approach bring iOS closer to Android: to diasable the New Architecture, user needs to modify the App's Info.plist and add a `RCTNewArchEnabled` boolean entry and set it to `NO`. The absence of the entry implies that the New Arch is enabled. (Defaults to enabled) This also deprecates the `RCTSetNewArchEnabled` function because it makes no sense now ## Context The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not. However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example: - New Arch / Hermes - Old Arch / Hermes - New Arch / JSC - Old Arch / JSC - ... ## Backward compatibility We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself. ## Changelog: [iOS][Deprecated] - deprecate the `RCT_NEW_ARCH_ENABLED` and the `RCTSetNewArchEnabled` Reviewed By: cortinico Differential Revision: D70885454
Summary: This change automates updating App's Info.plist with the new `RCTNewArchEnabled` boolean entry. The value depends on how the pod install is set up. In this way, we maintain the previous UX to enable/disable the New Arch. ## Context The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not. However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example: - New Arch / Hermes - Old Arch / Hermes - New Arch / JSC - Old Arch / JSC - ... ## Backward compatibility We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself. ## Changelog: [iOS][Added] - Reviewed By: cortinico Differential Revision: D70888212
f1f6cb2
to
7ed0792
Compare
This pull request was exported from Phabricator. Differential Revision: D70888212 |
Summary: This change automates updating App's Info.plist with the new `RCTNewArchEnabled` boolean entry. The value depends on how the pod install is set up. In this way, we maintain the previous UX to enable/disable the New Arch. ## Context The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not. However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example: - New Arch / Hermes - Old Arch / Hermes - New Arch / JSC - Old Arch / JSC - ... ## Backward compatibility We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself. ## Changelog: [iOS][Added] - Reviewed By: cortinico Differential Revision: D70888212
Summary: This change automates updating App's Info.plist with the new `RCTNewArchEnabled` boolean entry. The value depends on how the pod install is set up. In this way, we maintain the previous UX to enable/disable the New Arch. ## Context The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not. However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example: - New Arch / Hermes - Old Arch / Hermes - New Arch / JSC - Old Arch / JSC - ... ## Backward compatibility We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself. ## Changelog: [iOS][Added] - Reviewed By: cortinico Differential Revision: D70888212
This pull request has been merged in 3b3d502. |
…es (#51833) Summary: #49927 introduced a regression where a Ruby script would read compilation artifacts and fail, when the user has relative build directories set in XCode. After successful compilation `build/` dir and `DerivedData/` dir have `.plist` files that aren't in UTF-8 encoding and shouldn't be read by the script. If the user tries to reinstall pods at this point, he gets the following error:  This is how you enable relative build directories in XCode.  ## Changelog: [IOS] [FIXED] - Ignore `build/` and `DerivedData/` directories when reading `.plist` files. Pull Request resolved: #51833 Test Plan: After applying this patch the problem doesn't occur anymore on my machine. Reviewed By: cortinico Differential Revision: D76030133 Pulled By: cipolleschi fbshipit-source-id: 7ae8c2d0ce28b6925245a9172154e3dcafee126f
…es (#51833) Summary: #49927 introduced a regression where a Ruby script would read compilation artifacts and fail, when the user has relative build directories set in XCode. After successful compilation `build/` dir and `DerivedData/` dir have `.plist` files that aren't in UTF-8 encoding and shouldn't be read by the script. If the user tries to reinstall pods at this point, he gets the following error:  This is how you enable relative build directories in XCode.  ## Changelog: [IOS] [FIXED] - Ignore `build/` and `DerivedData/` directories when reading `.plist` files. Pull Request resolved: #51833 Test Plan: After applying this patch the problem doesn't occur anymore on my machine. Reviewed By: cortinico Differential Revision: D76030133 Pulled By: cipolleschi fbshipit-source-id: 7ae8c2d0ce28b6925245a9172154e3dcafee126f
hey @cipolleschi I have issues with the code after update to RN 0.80, this is probably specified to my codebase but just want to ask if this should be handled here or i need to play with this on our side. I use one 3rd party framework, which just sits in the the code
is just throwing error
changing code in
to:
but I am not sure if that's okey, please let me know and I can maybe create PR if that's okey or made some other path if you have better view ;-) |
Summary:
This change automates updating App's Info.plist with the new
RCTNewArchEnabled
boolean entry. The value depends on how the pod install is set up. In this way, we maintain the previous UX to enable/disable the New Arch.Context
The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not.
However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example:
Backward compatibility
We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself.
Changelog:
[iOS][Added] -
Reviewed By: cortinico
Differential Revision: D70888212