Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44182
## Changelog:
[iOS] [Fixed] - Fixed stale state on TouchableOpacity and TouchableBounce
When TouchableOpacity and TouchableBounce are unmounted, we need to reset their state. This includes animation state. If we don't do that, view is unmounted on the mounting layer and animation will not be applied. This leaves view in undefined state. In TouchableOpacity, it is view with reduced opacity. TouchableBounce that is view with applied transform.
This was reported in https://github.com/facebook/react-native/issues/44044
Reviewed By: rubennorte, cipolleschi
Differential Revision: D56416571
fbshipit-source-id: 01214ec8a5e07c80a609e082b955a30305ad8396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44185
This change will fix a symbol not found for JSC Runtime.
The `if` check was not a compile time check, therefore the symbol ended up in the binary even if it is not available.
Following this post on [Apple forum](https://forums.developer.apple.com/forums/thread/749534), this changes should do the trick.
## Changelog
[iOS][Fixed] - Fix Symbol not found: (_JSGlobalContextSetInspectable)
Reviewed By: hash3r
Differential Revision: D56425834
fbshipit-source-id: a37af51b078bd47a938e6b65d9d8e0f7506e746f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43327
<!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. -->
## Summary
Swift Pods require the use of [modular headers](https://blog.cocoapods.org/CocoaPods-1.5.0/) to be statically linked. To interop with Objective-C modules, you need to make the Objective-C module "define a Module", that is modular header export.
This is already the case for a few podspecs so they can be consumed in Swift libraries, but `ReactCommon` and `RCT-Folly` don't do this yet and therefore this breaks in a few libraries of mine, for example see this issue: https://github.com/mrousavy/react-native-vision-camera/issues/195.
If I were to include `ReactCommon` or `RCT-Folly` in my Swift library's podspec, the following error arises:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `VisionCamera` depends upon `RCT-Folly`, which does 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.
```
So this PR fixes this issue by allowing Swift libraries to consume the `ReactCommon` and `RCT-Folly` podspecs since they now export modular headers.
## 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] - Expose Modular Headers for `ReactCommon` podspec
[General] [Fixed] - Expose Modular Headers for `RCT-Folly` podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/31858
Test Plan: * Add s.dependency "ReactCommon" or RCT-Folly to a Swift pod and see what happens. (See https://github.com/mrousavy/react-native-vision-camera/pull/273)
Reviewed By: dmytrorykun
Differential Revision: D54539127
Pulled By: cipolleschi
fbshipit-source-id: 2291cc0c8d6675521b220b02ef0c3c6a3e73be38
Summary:
This change fixes a couple of issues within the RCTUIManager:
* it calls the right method in the `super` branches (although they should neve be executed)
* it invert the call order between the `_registry` and the `uiManager` to avoid extra calls into the `viewForReactTag`.
## Changelog:
[Internal] - Use the right method in super and invert the order of where we search for views.
## Facebook:
See S397861 and T180527210 for more information.
Reviewed By: javache
Differential Revision: D54246220
fbshipit-source-id: 1c7503ad3e80cf50ecc016a984ca180a19b73cc0
Summary:
We might want to publish some new versions of React Native with experimental feature to allow some partners to test whether those versions fixes some reported issues, before creating a proper stable version for the whole ecosystem.
The infra is mostly [setup for this](https://www.internalfb.com/code/fbsource/[496a64d180faab501b8598aa0ec26d47454fb961]/xplat/js/react-native-github/scripts/releases/utils/version-utils.js?lines=149), already. The only detail we need to take care of is not to move the `next` tag.
[Internal]
Reviewed By: cortinico, huntie
Differential Revision: D56578456
fbshipit-source-id: 8dcc674aab5f85077c1b3e6580c5aeb99226eff8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44188
The current approach used for `batchRenderingUpdatesInEventLoop` is not compatible with Android due to limitations in its props processing model. The raw props changeset is passed through to Android, and must be available for the Android mounting layer to correctly apply changes.
We have some logic to merge these payloads when multiple ShadowNode clones take place but were previously assuming that a ShadowTree commit was a safe state to synchronize.
In the current implementation this means that two commits driven from layout effects (triggering states A → B → C) may cause Android to observe only the B → C props change, and miss out on any props changed in A → B.
Changelog: [Android][Fixed] Cascading renders were not mounting correctly when `batchRenderingUpdatesInEventLoop` is enabled.
Reviewed By: rubennorte
Differential Revision: D56414689
fbshipit-source-id: 7c74d81620db0f8b7bd67e640168afc795c7a1d7
Summary:
Supports the removal of Flipper from the template in 0.74, paried with additional blog post messaging: https://reactnative.dev/blog/2024/04/22/release-0.74#removal-of-flipper-react-native-plugin.
Changelog:
[General][Changed] - Update "Open Debugger" action to print extended Flipper guidance
Reviewed By: cipolleschi
Differential Revision: D56705236
fbshipit-source-id: d7e869625262ebb02bc2454c924f832cccfbcd31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44180
Changelog: [General][Changed] Update Chrome launch flags for `--experimental-debugger` launch flow
Internally at Meta, we've been testing the experimental debugger launch flow with a different set of Chrome flags than are currently shipped in open source. This diff fixes those differences:
* Removes `--disable-backgrounding-occluded-windows`
* Adds `--guest`
Reviewed By: EdmondChuiHW
Differential Revision: D56418271
fbshipit-source-id: 884c5746e93cad89f17e4ef9e3ef193a2a454eb5
Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
# Conflicts:
# packages/rn-tester/RNTesterPods.xcodeproj/project.pbxproj
Summary:
After a [recent change](https://github.com/facebook/react-native/commit/90296be1d4fab09a52e02dd09f34f819136d0a07) we break part of the integration with the debug menu, which is was using the presence/absence of the bridge to decide whether we were in bridge or bridgeless.
For backward compatibility reasosn, the bridge ivar is now populated with the bridgeProxy, so just checking whether is nil or not is not enough to verify whether we are in bridge or in bridgeless mode anymore.
## Changelog:
[iOS][Fixed] - Make sure that the Open Debugger appears in bridgeless mode
Reviewed By: fkgozali
Differential Revision: D56067897
fbshipit-source-id: e2501ed730ff35bc755c24ef400130c551032e28
Summary:
We would set the value of _bridge ivar to bridgeProxy for turbo module in bridgeless mode in https://github.com/facebook/react-native/issues/43757 , so we need to change the way of bridgeless/bridge check.
## Changelog:
[IOS] [FIXED] - Change bridgeless check in dev menu
Pull Request resolved: https://github.com/facebook/react-native/pull/43976
Test Plan: Dev menu shows bridgeless/bridge mode correctly.
Reviewed By: christophpurrer
Differential Revision: D56056640
Pulled By: cipolleschi
fbshipit-source-id: 1358c3027c1d5f12c70dd4486cc1d5975c7a185a
* Support launchOptions in bridgeless mode (#43757)
Summary:
Support launchOptions in bridgeless mode
bypass-github-export-checks
[IOS] [FIXED] - Support launchOptions in bridgeless mode
Pull Request resolved: https://github.com/facebook/react-native/pull/43757
Test Plan:
```
useEffect(() => {
const processInitialURL = async () => {
const url = await Linking.getInitialURL();
if (url !== null) {
console.log(`Initial url is: ${url}`);
}
};
processInitialURL();
}, []);
```
Reviewed By: javache
Differential Revision: D55790758
Pulled By: cipolleschi
fbshipit-source-id: 0f6aa6bdcebfc5bc42d632bea9193f122c1eb84f
* Fix Connect to Metro after Reload in Bridgeless mode (#43994)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43994
We received [this issue](https://github.com/facebook/react-native/issues/43764) from OSS where an app can't connect to Metro on reloads in the following scenario:
* Start the App when metro does not run.
* Observe the error screen
* Start Metro
* Press Reload
* Observe the error message again
While the desired behavior should be to connect to Metro now that this is running.
The root cause of the problem is that the RCTHost is initialized with a value of the `bundleURL` that is `nil`. Upon reload, the RCTHost is **not** recreated: the instance is restarted, but with the previous `bundleURL`, which is still `nil`.
The solution is to initialize the `RCTHost` with a closure that re-evaluate the `bundleURL` whenever it is invoked and to evaluate it only on `start`, to keep the initialization path light.
This way, when the app is started with Metro not running, the `bundleURL` is `nil`. But when it is reloaded with Metro starting, the `bundleURL` is properly initialized.
Note that the changes in this diff are not breaking as I reimplemented (and deprecated) the old initializer so that they should work in the same way.
[iOS][Fixed] - Let RCTHost be initialized with a function to provide the `bundleURL` so that it can connect to metro on Reload when the url changes.
Reviewed By: dmytrorykun
Differential Revision: D55916135
fbshipit-source-id: 6927b2154870245f28f42d26bd0209b28c9518f2
* Fix badly resolved merge conflicts
---------
Co-authored-by: zhongwuzw <zhongwuzw@qq.com>
Summary:
Changelog: [iOS][Added]
this change will be included in the RN CLI. so all new apps running the RN CLI to get created will get this manifest. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53682756
fbshipit-source-id: 0426fe0002a3bc8b45ef24053ac4228c9f61eb85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43999
Currently NewArch-BridgeMode is partially broken when creating views via `ReactDelegate`.
That's because we're using the ctor that doesn't account for `Boolean: fabricEnabled`.
That means that the `RootView` that it will be created are all having setIsFabric(FALSE).
This is causing problems like whitescreens on several reload + multiple warnings such as:
```
E com.facebook.react.bridge.ReactNoCrashSoftException: Cannot get UIManager because the context doesn't contain an active CatalystInstance.
```
Fixes#43692
See for more context on this issues: https://github.com/facebook/react-native/issues/43692
Changelog:
[Android] [Fixed] - Fix bridge mode by constructing ReactDelegate correctly
Reviewed By: cipolleschi
Differential Revision: D55921078
fbshipit-source-id: 2c21d089a49538402d546177bcdb26c8d7d5fbc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43971
It turns out that we forgot to add a listener for the orientation change event in Bridgeless.
We used to have `UIApplicationDidChangeStatusBarOrientationNotification` but this is slightly unreliable because there might be use cases where the status bar has been hidden and, therefore, the event is not triggered.
This should fix an issue reported by OSS.
## Changelog:
[iOS][Fixed] - Make sure that the New Architecture listens to orientation change events.
Reviewed By: cortinico
Differential Revision: D55871599
fbshipit-source-id: c9b0634ec2126aa7a6488c2c56c87a9610fa1adf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43967
Following up https://github.com/facebook/react-native/issues/43943, the metro loading banner is presented twice in Bridgeless mode.
This happens because both the RCTInstance and the RCTHost are listening to the Reload Command and issuing the instructions to refetch the JSBundle and to present the banner.
The RCTInstance should not concern itself with lifecycle events, owned by the RCTHost.
## Changelog:
[iOS][Fixed] - Avoid to show Metro Loading banner twice.
Reviewed By: cortinico
Differential Revision: D55870640
fbshipit-source-id: addb67d3226f7d7db20736309172a42fc15f3aa3
Summary:
Working with gabrieldonadel, we realized that static frameworks of the React-RendererRuntime are not following the proper folder structure.
When a user tries to import `ReactCommon/RCTHost` in the app delegate, for example, the user ends up with an error and they can't find the files.
These changes fixes this by establishing the right folder structure in the static frameworks
## Changelog:
[Internal] - Make sure that React-RuntimeCore and JSErrorHandler are created with the proper structure for static frameworks
Pull Request resolved: https://github.com/facebook/react-native/pull/43846
Test Plan:
Tested locally on an app with 0.74.
Before: it failed to build.
After: it build successfully.
Reviewed By: cortinico
Differential Revision: D55741581
Pulled By: cipolleschi
fbshipit-source-id: 11ac0882d3feea05ef8904d55856ba5704b7a3b8
Summary:
In the Old Architecture and for Swift Libraries, these two methods are used to initialize a new disctionary but their implementation was missing so some libraries like lottie were failig to build.
## Changelog:
[Internal] - Implement missing `count` and `keyEnumerator` methods for RCTComposedViewRegistry
Pull Request resolved: https://github.com/facebook/react-native/pull/43850
Test Plan: Tested locally with the repro provided by SWM
Reviewed By: javache
Differential Revision: D55743648
Pulled By: cipolleschi
fbshipit-source-id: 7bdb92625341cd704b8b09920ab3223a2ca61a54
Summary:
With 0.74.rc-5 one bug which related to errors was fixed (https://github.com/facebook/react-native/issues/41950). However, the fix introduced another one: the shape of Error objects that come from native modules has changed. This PR attempts to fix that, though it's not (yet) doing it in a way that would be 100% compatible with the old arch.
The problem was observed on iOS, not sure what the situation is on Android but believe it's okay there.
edit: on Android, there are no issues but the `message` field is enumerable, so that part is different from ios (see logs below).
Consider this code, where `error` is produced from a promise rejection inside of a native module.
```ts
console.log(
'own properties: ',
JSON.stringify(Object.getOwnPropertyNames(error), null, 2),
);
console.log(
'own enumerable properties: ',
JSON.stringify(Object.entries(error), null, 2),
);
```
These are the results for
<details>
<summary>Old architecture</summary>
```
LOG Running "google-one-tap-example" with {"rootTag":1,"initialProps":{}}
LOG own properties: [
"stack",
"code",
"message",
"domain",
"userInfo",
"nativeStackIOS"
]
LOG own enumerable properties: [
[
"code",
"-5"
],
[
"message",
"RNGoogleSignIn: The user canceled the sign in request., Error Domain=com.google.GIDSignIn Code=-5 \"The user canceled the sign-in flow.\" UserInfo={NSLocalizedDescription=The user canceled the sign-in flow.}"
],
[
"domain",
"com.google.GIDSignIn"
],
[
"userInfo",
{
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
],
[
"nativeStackIOS",
[
"0 ReactTestApp 0x0000000102f4a6d8 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x0000000102eeedd0 __41-[RCTModuleMethod processMethodSignature]_block_invoke_2.73 + 152",
"2 ReactTestApp 0x0000000102e2ae24 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x0000000102e2aa8c -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x0000000102e2a8e0 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x0000000102e28628 __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x0000000102dc9d80 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
]
]
]
```
</details>
<details>
<summary>RN 74 rc-5 (with bridgeless on)</summary>
```
(NOBRIDGE) LOG Bridgeless mode is enabled
(NOBRIDGE) LOG Running "google-one-tap-example" with {"rootTag":1,"initialProps":{"concurrentRoot":true},"fabric":true}
(NOBRIDGE) LOG own properties: [
"stack",
"message",
"cause"
]
(NOBRIDGE) LOG own enumerable properties: [
[
"cause",
{
"code": "-5",
"message": "RNGoogleSignIn: The user canceled the sign in request., Error Domain=com.google.GIDSignIn Code=-5 \"The user canceled the sign-in flow.\" UserInfo={NSLocalizedDescription=The user canceled the sign-in flow.}",
"nativeStackIOS": [
"0 ReactTestApp 0x00000001023a7b38 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x00000001026cf774 ___ZZN8facebook5react15ObjCTurboModule13createPromiseERNS_3jsi7RuntimeENSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEU13block_pointerFvU13block_pointerFvP11objc_objectEU13block_pointerFvP8NSStringSH_P7NSErrorEEENK3$_0clES4_RKNS2_5ValueEPSQ_m_block_invoke.57 + 332",
"2 ReactTestApp 0x0000000102270958 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x00000001022705c0 -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x0000000102270414 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x000000010226e15c __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x000000010220f328 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
],
"domain": "com.google.GIDSignIn",
"userInfo": {
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
}
]
]
```
</details>
<details>
<summary>with the diff from this PR</summary>
```
(NOBRIDGE) LOG own properties: [
"stack",
"message",
"code",
"nativeStackIOS",
"domain",
"userInfo"
]
(NOBRIDGE) LOG own enumerable properties: [
[
"code",
"-5"
],
[
"nativeStackIOS",
[
"0 ReactTestApp 0x000000010083b8f8 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x0000000100b63534 ___ZZN8facebook5react15ObjCTurboModule13createPromiseERNS_3jsi7RuntimeENSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEU13block_pointerFvU13block_pointerFvP11objc_objectEU13block_pointerFvP8NSStringSH_P7NSErrorEEENK3$_0clES4_RKNS2_5ValueEPSQ_m_block_invoke.57 + 332",
"2 ReactTestApp 0x0000000100704718 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x0000000100704380 -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x00000001007041d4 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x0000000100701f1c __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x00000001006a30e8 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
]
],
[
"domain",
"com.google.GIDSignIn"
],
[
"userInfo",
{
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
]
]
```
</details>
You see there is a change compared to old arch because `message` is no longer own enumerable property. If that needs to change (I guess it should), it'd be nice if someone more familiar with JSI pointed me in the right direction. Even with this inconsistency, the PR is an improvement and would be nice to have this fix included in the next RC.
This is output from Chrome's console for completeness, just to have something to compare to:
```
let err = new Error('hello')
undefined
Object.getOwnPropertyNames(err)
> ['stack', 'message']
Object.entries(err)
> []
```
bypass-github-export-checks
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - add missing fields to native errors in new arch
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43649
Test Plan: Tested locally with an example app running RN 74-rc 5
Reviewed By: cortinico
Differential Revision: D55690184
Pulled By: cipolleschi
fbshipit-source-id: 60a857b9871af888dcd526782b5e6b73c07c051a
Summary:
This allows build configuration named like `StagingDebug` to match with settings applied to `Debug` This fixes https://github.com/facebook/react-native/issues/43185
Custom build setting were only applied to `Debug` build configurations, preventing configurations named `StagingDebug` or similar to access the new experimental debugger, as reported in https://github.com/facebook/react-native/issues/43185
This now applies the setting to every configuration ending with `Debug`
## Changelog:
[IOS] [CHANGED] - fix: build settings for custom build configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/43780
Reviewed By: dmytrorykun
Differential Revision: D55688996
Pulled By: cipolleschi
fbshipit-source-id: 1f34cd722f6acfaa08d3377e19a04d08af97ed7c
Arushi Kesarwani
Samuel Susla
Riccardo Cipolleschi
Marc Rousavy
Distiller
Riccardo Cipolleschi
Alex Hunt
Nicola Corti
Pieter De Baets
Rubén Norte
Alex Hunt
Moti Zilberman
Distiller
Distiller
Phillip Pan
zhongwuzw
Distiller
Evert Eti
Distiller
Vojtech Novak
Jean-Baptiste LARRIVIERE
Dmitry Rykun
Distiller
Szymon Rybczak