Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52648
This creates a `debugOptimized` build type for React Native Android, meaning that we can run C++ optimization on the debug build, while still having the debugger enabled. This is aimed at improving the developer experience for folks developing on low-end devices or emulators.
Users that intend to debug can still use the `debug` variant where the full debug symbols are shipped.
Changelog:
[ANDROID] [ADDED] - Create a debugOptimized buildType for Android
Reviewed By: cipolleschi
Differential Revision: D78425138
fbshipit-source-id: c1e9ea3608e7df10fb871a5584352f0747cf560b
Summary:
This creates a `debugOptimized` build type for React Native Android, meaning that we can run C++ optimization on the debug build, while still having the debugger enabled. This is aimed at improving the developer experience for folks developing on low-end devices or emulators.
Users that intend to debug can still use the `debug` variant where the full debug symbols are shipped.
## Changelog:
[ANDROID] [ADDED] - Create a debugOptimized buildType for Android
Pull Request resolved: https://github.com/facebook/react-native/pull/52620
Test Plan:
Tested locally with RNTester by doing:
```
./gradlew installDebugOptimized
```
This is the output of the 3 generated .aar. The size difference is a proof that we're correctly stripping out the C++ debug symbols:
<img width="193" height="54" alt="Screenshot 2025-07-15 at 17 49 50" src="https://github.com/user-attachments/assets/584a0e8d-2d17-40d4-ac29-da09049d6554" />
<img width="235" height="51" alt="Screenshot 2025-07-15 at 17 49 39" src="https://github.com/user-attachments/assets/eda8f9e7-3509-4334-8c16-990e55caa04d" />
<img width="184" height="52" alt="Screenshot 2025-07-15 at 17 49 32" src="https://github.com/user-attachments/assets/a5c94385-bc00-4484-b43e-088ee039827f" />
Rollback Plan:
Reviewed By: cipolleschi
Differential Revision: D78351347
Pulled By: cortinico
fbshipit-source-id: 568a484ba8d2ee6e089cabc95451938e853fbc54
Summary:
When running a project in a path that contains any spaces, the scripts have several escape patterns that don't handle this path correctly. For example, `"/absolute/path/with spaces"` may be rendered as `/absolute/path/with spaces` and this shows as an output error such as `No such file or directory /absolute/path/with`
This was likely a longstanding issue, but is unexpected for some beginners that first try out React Native. While it's not recommended to create a path like this, it's certainly not hard to make this mistake.
## Changelog:
[IOS] [FIXED] - fix scripts for paths containing whitespaces
Pull Request resolved: https://github.com/facebook/react-native/pull/53194
Test Plan: tested locally; create a React Native or Expo project in a folder containing a space (e.g. `/my/path/with spaces/new-app` and build the project. With changes applied, the build should succeed. (There's related failures in `expo/expo` that need fixing too)
Reviewed By: robhogan
Differential Revision: D79993537
Pulled By: cipolleschi
fbshipit-source-id: b32697ce2405c403c410b3ceaed7e161e4a48537
Summary:
Symbol files wasn't copied correctly when building - as with bundles we did overwrite the files and ended up with only the last symbol file.
This commit fixes this by mapping the framework build folder architecture type to the xcframework slices creating the correct file structure under the Symbols folder.
- Each slice gets a folder with the architecture name under Symbols containing the dSym folder for that slice
- Refactored getting correct architecture folder into a separate function.
- Refactored target folder lookup in copyBundles
- Removed unused async modifier on function
## Changelog:
[IOS] [FIXED] - Fixed how we copy and build the Symbols folder when precompiling ReactNativeDependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/53353
Test Plan: Run nightlies and verify that ReactNativeDependencies.framework.dSym files contains symbol files for all architectures.
Reviewed By: cortinico
Differential Revision: D80692019
Pulled By: cipolleschi
fbshipit-source-id: 77983bc29d1965edf3bc0fcbd9cb3177071991d3
Summary:
When building the xcframeworks on iOS we're including the file `jsi/jsi.cpp` in the Swift Package. This file is also included in Hermes and React Native should use the hermes version of these symbols. This is even described (but overlooked) in the React-jsi podspec file.
This causes the error seen in the bug addressed by this commit.
The fix is to exclude the `jsi/jsi.cpp` file from the jsi target in our swift package.
Fixes https://github.com/facebook/react-native/issues/53257
## Changelog:
[IOS] [FIXED] - Fixed wrong jsi symbols in use when using React.xcframework
Pull Request resolved: https://github.com/facebook/react-native/pull/53266
Test Plan: Tested using a precompiled xcframework in the reproduction repository.
Reviewed By: rshest
Differential Revision: D80252131
Pulled By: cipolleschi
fbshipit-source-id: 915e94a1d80c2f45575e58d8054239484e861285
Summary:
When copying bundle files from the platform folders in the .build output, the script had a bug where all bundles were copied - meaning that only the last one would be in the resulting xcframework output.
This caused an issue when we tried to publish an app built with precompiled binaries to AppStore where the field `CFBundleSupportedPlatforms` was wrong and caused the submission to be rejected. This was caused by the script copying the wrong bundle file into the final xcframework outputs.
This issue is described here:
https://github.com/react-native-community/discussions-and-proposals/discussions/923#discussioncomment-14089245
This commit fixes the above error by using the iOS 15 `vtool` to show the actual platform for a given framework and then making sure we don't copy bundles in the wrong way.
Testing this on my local machine for iOS/iOS-simulator/MacOS/catalyst yields the following results (before/after this fix):
**Before:**
```bash
Copying bundles to the framework...
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
```
**After:**
```bash
Copying bundles to the framework...
../.build/Build/Products/Debug/ReactNativeDependencies_glog.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug/ReactNativeDependencies_boost.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug/ReactNativeDependencies_folly.bundle → macos-arm64_x86_64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_glog.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_boost.bundle → ios-arm64
../.build/Build/Products/Debug-iphoneos/ReactNativeDependencies_folly.bundle → ios-arm64
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-iphonesimulator/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-simulator
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_glog.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_boost.bundle → ios-arm64_x86_64-maccatalyst
../.build/Build/Products/Debug-maccatalyst/ReactNativeDependencies_folly.bundle → ios-arm64_x86_64-maccatalyst
```
## Changelog:
[IOS] [FIXED] - Fixed copying bundles correctly to xcframeworks when precompiling ReactNativeDependencies.xcframework
Pull Request resolved: https://github.com/facebook/react-native/pull/53325
Test Plan: Ensure that the info.plist files in the nightlies for the ReactNativeDepdendencies.xcframework has the correct bundles for its targets.
Reviewed By: andrewdacenko
Differential Revision: D80457335
Pulled By: cipolleschi
fbshipit-source-id: aeb4166f66218f72bdd29b6fc579fcc7b6d12844
Summary:
After fixing an isssue with ReactnativeDependencies and how it built symbols (https://github.com/facebook/react-native/issues/53353) this commit will align the output of the Symbols folder for the two frameworks.
Previously we had an output in the Symbols folder that looked like this (from a local build on my machine)
- catalyst
- iphone
- iphonesimulator
After this we now have the more correct arcitecture names on these folders:
- ios-arm64
- ios-arm64_x86_64-simulator
- ios-arm64_x86_64-maccatalyst
This is in line with how the ReactNativeDependencies Symbol folder is set up.
## Changelog:
[IOS] [FIXED] - Aligned Symbols folder in React.xcframework symbols with ReactNativeDependencies.xcframework symbols.
Pull Request resolved: https://github.com/facebook/react-native/pull/53354
Test Plan: Nightlies
Reviewed By: cortinico
Differential Revision: D80692098
Pulled By: cipolleschi
fbshipit-source-id: e952b087d5dbdeb929b45d9e6d3d7e077c9d05cc
Summary:
XCode 26 introduces building explicit swift modules turned on (SWIFT_ENABLE_EXPLICIT_MODULES). This breaks building with precompiled binaries.
This commit fixes this by adding a step when not building from source where we explicitly set the `SWIFT_ENABLE_EXPLICIT_MODULES` flag to `NO`.
## Changelog:
[IOS] [FIXED] - Added setting SWIFT_ENABLE_EXPLICIT_MODULES=NO when using precompiled to support Xcode 26
Pull Request resolved: https://github.com/facebook/react-native/pull/53457
Test Plan:
```bash
npx react-native-community/cli init MyApp --version nightly --skip-install
cd MyApp
yarn
cd ios
bundle install
RCT_USE_RN_DEP=1 RCT_USE_PREBUILT_RNCORE=1 bundle exec pod install
```
Build above app with Xcode 26 and verify that it no longer fails
Reviewed By: motiz88
Differential Revision: D81025367
Pulled By: cipolleschi
fbshipit-source-id: 1db7c4d7de07d62f43b355aa784d7d9de478023c
Summary:
When running `RCT_USE_PREBUILT_RNCORE=1 RCT_USE_RN_DEP=1 pod install` I'm getting an error: `cp: framework/packages/react-native/..: File exists`
This is not seen consistently by everyone but I've seen in reported one more time at Expo. Could be related to running MacOS 26.
Somehow, apparently, the `..` is being treated as a literal directory name and cp is trying to create a directory named `..` inside `framework/packages/react-native/` which is not what we want. Using `/.` avoids that.
---
What also seemed to work(around) was to change `mkdir -p framework/packages/react-native` to `mkdir -p framework/packages/` and then `cp` can create the `framework/packages/react-native/..` folder. But this is definitely more confusing.
## Changelog:
Pick one each for the category and type tags:
[IOS] [FIXED] - fix "file exists" error in `ReactNativeDependencies.podspec`
Pull Request resolved: https://github.com/facebook/react-native/pull/53136
Test Plan: tested locally, and in CI on older macOS: https://github.com/expo/expo/pull/38631 (the ios build succeeds)
Reviewed By: rshest
Differential Revision: D79990895
Pulled By: cipolleschi
fbshipit-source-id: 44ff9034800d3acd4e55ec39aabfb326382372cb
Summary:
The `aria-label` prop was ignored on `TextInput` component. Which resulted in screen reader not able to read it.
This PR forwards `aria-label` to `accessibilityLabel` in a manner similar to e.g. `View` and `Text`
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - a11y: fix `aria-label` on `TextInput`
Pull Request resolved: https://github.com/facebook/react-native/pull/53051
Test Plan:
Run RNTester => TextInput => Accessibility section under Accessibility Inspector or screen reader.
iOS fixed:
https://github.com/user-attachments/assets/68c3a2ef-7dfe-479c-97fc-cbe72108c45c
iOS baseline:
https://github.com/user-attachments/assets/2e8372ba-10dc-47d2-b6b1-9f664000de7d
Reviewed By: andrewdacenko
Differential Revision: D79635413
Pulled By: rshest
fbshipit-source-id: dd2f583d67c6c6c6393e02c5fe534308e1e2f921
Summary:
`#include <ReactCommon/RuntimeExecutor.h>` stopped working in react-native 0.81 when using frameworks because it is not part of ReactCommon anymore when the split happened for iOS.
to fix this I am including RuntimeExecutor in search headers same way we include ReactCommon.
## Changelog:
[IOS] [FIXED] - Fix import RuntimeExecutor.h with USE_FRAMEWORKS
Pull Request resolved: https://github.com/facebook/react-native/pull/53099
Test Plan:
You can enable USE_FRAMEWORKS and do `#include <react/renderer/uimanager/UIManager.h>` (which react-native-reanimated is doing).
Build will fail complaining that it can't find ReactCommon/RuntimeExecutor.h which is included in UIManager.h
Add my patch, it will work and build successfully
Reviewed By: cortinico
Differential Revision: D79796637
Pulled By: cipolleschi
fbshipit-source-id: f8bb669cfb9f4414653655ed98d2cc6bb431a3e5
Summary:
The `react-native/metro-config` peer was added in https://github.com/facebook/react-native/commit/fe2bcbf4ba7ce983fac0cd09727c165517b6337f / https://github.com/facebook/react-native/issues/51836 by robhogan
Side-note: It's pulled in via `react-native/community-cli-plugin` which is a direct dependency of `react-native` for the `scripts/bundle.js` script. While, for expo, we'd love to find a way to make this an optional dependency (to avoid excessive deps that `expo` replaces otherwise), for now, it's a direct dependency.
The problem here is that this isn't optional, which means:
- with auto-installing peer dependencies it is directly fulfilled (while `react-native-community/cli` is already marked as optional and skipped)
- with legacy/non-auto peer-dependencies it is flagged as missing, but in an Expo project it wouldn't make sense to install directly
This causes a **package manager regression in the form of either a peer dependency warning**, that shouldn't be fulfilled in an Expo project, or (in the best case scenario) pulls in dependencies [that a user does not need](https://npmgraph.js.org/?q=%40react-native%2Fmetro-config#zoom=w&select=exact%3A%40react-native%2Fmetro-config%400.81.0).
An error message is already in place to inform the user of this being missing when it's not installed, so marking it as optional seems appropriate.
## Changelog:
[INTERNAL] [FIXED] Mark added `react-native/metro-config` peer dependency as optional
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/53314
Test Plan:
Warnings like the following won't occur in fresh Expo (54/preview/`next`) projects
```
warning "workspace-aggregator-484d9ec3-587b-43cb-97de-4dcce3876578 > microfoam-mobile > react-native > react-native/community-cli-plugin@0.81.0" has unmet peer dependency "react-native/metro-config@*".
```
Reviewed By: cortinico
Differential Revision: D80450287
Pulled By: robhogan
fbshipit-source-id: c622fd4c24025676c0ec74de826f863f1e291669
* [ios][precompile] Add use_frameworks resolve method
To be able to handle cocoapods USE_FRAMEWORKS with both dynamic/static linkage and precompiled we needed a common way to resolve this.
The issue was that when using precompiled and USE_FRAMEWORKS our precompiled framework caused the resulting Pods project to only include header files - hence there where no need to change the header_mappings_dir which a lot of the podspecs did.
A method was added that handles this in a common way.
* [ios][precompile] added resolve_use_frameworks to podspecs
Replaced logic for resolving header mappings and module name using the new method `resolve_use_frameworks` in all podspecs.
Also added `React-oscompat` dependency on `React-jsiinspector_modern` which failed when linkage was "dynamic".
* [ios][precompile] added explicit handling of ReactCoden
When using precompiled and building with frameworks (USE_FRAMEWORKS) we need to explicitly add the correct path to ReactCodegen when calling `create_header_search_path_for_frameworks` to ensure libraries can access their codegen files.
This commit adds an explicit check to make sure we add the correct path when using frameworks and the pod is ReactCodegen.
Added includes in the NativeCXXModuleExample.cpp file to test this.
* Update packages/react-native/scripts/cocoapods/utils.rb
Co-authored-by: Riccardo Cipolleschi <cipolleschi@meta.com>
* codereview: removed test include files
* codereview: fixed issue in ruby.rb
After a github `suggestion` we had a superfluous `end`. Sorry for that.
---------
Co-authored-by: Christian Falch <christian.falch@gmail.com>
Co-authored-by: Christian Falch <875252+chrfalch@users.noreply.github.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53013
Quick fix to restore CI on `main`. `actions/setup-node` is now pulling Node.js `24.5.0`, which introduces a bug affecting `packages/dev-middleware/src/__tests__/` Jest tests.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D79551277
fbshipit-source-id: 51951ad8ffe376a478da268b50aa54ac2d9bba03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52803
I've just realized that our build suffer from a race condition. Specifically
libraries codegen needs to be executed before the app starts the evaluating CMake files.
Otherwise this could lead to a lot of missing files or folders.
Changelog:
[Android] [Fixed] - **rngp:** Fix a race condition with codegen libraries missing sources
Reviewed By: huntie
Differential Revision: D78886347
fbshipit-source-id: f59c201d2eab651bc4a08cf5a795acd379d18186
Summary:
bypass-github-export-checks
Pull Request resolved: https://github.com/facebook/react-native/pull/52783
This change reverts D78158734 which was a patch to make the dynamic frameworks work properly because we were not exporting the FBReactNativeSpec headers in prebuilds correctly.
This change fixes this, by exposritng those headers correctly.
[Internal] -
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D78803425
fbshipit-source-id: 5613ed0c790455ea86668eeb436f7b78a0c80918
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52878
Now that Metro is bumped to also support node >= 20.19.4
we should be able to run test_js on `main` against 20.19.4
Changelog:
[Internal] [Changed] -
Reviewed By: robhogan, motiz88
Differential Revision: D79087608
fbshipit-source-id: 2161a893ab2fd88dc7eb1b35aa385704962018e8
Summary:
Hello, I work on [Radon IDE](ide.swmansion.com) I encountered an issue while adding support for react native 81, this PR solves it:
In https://github.com/facebook/react-native/issues/51023 EvanBacon removed `displayName` filed from `View` component adding the following comment:
>Remove displayName in favor of component name. I'm not 100% sure this is a full fallback but it is valid according to react/display-name eslint rule—https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/display-name.md
Unfortunately the Fabric renderer uses the `displayName` property to generate the name of the component for the inspector functionality and in absence of it generates a name that might be confusing to the end user:
<img width="351" height="283" alt="Screenshot 2025-07-17 at 21 27 37" src="https://github.com/user-attachments/assets/852246aa-6586-4684-b80e-5d70b9678c6e" />
Problem is not specific to Radon and happens in chrome devtools as well:
<img width="501" height="130" alt="Screenshot 2025-07-17 at 22 16 52" src="https://github.com/user-attachments/assets/3514dd02-59f7-473a-87b1-6ed325d2034c" />
This PR brings back the `displayName` property to fix that.
[INTERNAL] [FIXED] - Bring back the displayName property to the View component
Pull Request resolved: https://github.com/facebook/react-native/pull/52688
Test Plan:
- Run the application
- open chrome devtools and navigate to "components" tab
- before changes the View components would show up as `View_withRef` after they are named `View`
Rollback Plan:
Reviewed By: lunaleaps, cortinico
Differential Revision: D78512254
Pulled By: alanleedev
fbshipit-source-id: 46e4a224b09fe3fb938c055a675f687c86d7ddcb
Co-authored-by: filip131311 <159789821+filip131311@users.noreply.github.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52660
The documentation for those methods mention that users should override them to
provide their own implementation.
However those vals are not `open` so users cannot really override them.
This fixes it.
See more context on https://github.com/facebook/react-native/pull/48800#issuecomment-3082665024
So this was practically a breaking change, that I'm attempting to mitigate.
Changelog:
[Android] [Fixed] - Make accessors inside HeadlessJsTaskService open again
Reviewed By: cipolleschi
Differential Revision: D78479162
fbshipit-source-id: eefc7332e2004198cd6bd64b60a66215f137ad4a
* Clean up feature flag preventShadowTreeCommitExhaustionWithLocking (#52791)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52791
Changelog: [internal]
This cleans up this feature flag as it doesn't work as intended. We'll try another approach with a different flag instead.
Reviewed By: sammy-SC
Differential Revision: D78815892
fbshipit-source-id: 4c651a3a225de9cfb54d00346343c7f2e3bea1d5
* Implement solution for ShadowTree commmit exhaustion using recursive locks (behind a flag) (#52795)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52795
Changelog: [internal]
This is another attempt to fix https://github.com/facebook/react-native/issues/51870, inspired by https://github.com/facebook/react-native/pull/52314 but gated behind a feature flag until we've tested it carefully.
Reviewed By: sammy-SC
Differential Revision: D78817100
fbshipit-source-id: 45e6cae019b212528f2b2e74b9f52fe43d07f537
* [LOCAL] Correctly sort preventShadowTreeCommitExhaustion after merge conflict
---------
Co-authored-by: Rubén Norte <rubennorte@meta.com>
* Lower minimum Node.js version to 20.19.4 (#52678)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52678
From partner feedback, there's still appetite to support Node 20.x for the next <1y of life. Lower min version to `20.19.4` (Jul 2025) and widen test matrix in CI.
Changelog:
[General][Breaking] - Our new minimum Node version is Node.js 20 (Overrides #51840)
Reviewed By: cortinico
Differential Revision: D78494491
fbshipit-source-id: c8d9dc6250cb11f8a12ca7e761b65f4a8dae9265
* Bump Metro to ^0.83.1, lower minimum Node.js version to 20.19
Summary:
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.83.1
The only public-facing change is a lowering of the minimum Node.js version from 22.14 to 20.19.
This will need picking to RN `0.81-stable`
Changelog: [General][Changed] Metro to ^0.83.1
Reviewed By: huntie
Differential Revision: D78895160
fbshipit-source-id: b9ccffe972249b73897f51c14873861e57a97161
* Do not setup-node twice in test_js (#52737)
Summary:
I've noticed that test_js (20) and test_js (24) are actually running on Node 22.
That's because the `yarn-install` action is invoking setup-node again with the default value (22).
This changes it. Also I'm cleaning up the workflows so that every `yarn-install` invocation is happening just after the `setup-node` invocation.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/52737
Test Plan: CI which will most likely be red for test_js (20) so will need a follow-up
Reviewed By: cipolleschi
Differential Revision: D78664671
Pulled By: cortinico
fbshipit-source-id: c73390930d1511d1bf0f2d4ea92e83f50b10247f
---------
Co-authored-by: Alex Hunt <huntie@meta.com>
Co-authored-by: Rob Hogan <robhogan@meta.com>
Co-authored-by: Nicola Corti <ncor@meta.com>
* Implement mechanism to prevent ShadowTree commit exhaustion (#52645)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52645
Changelog: [internal]
This add a new feature flag to test a fix for https://github.com/facebook/react-native/issues/51870
Reviewed By: cortinico, sammy-SC
Differential Revision: D78418504
fbshipit-source-id: 2792026b6936393d196fd1e3162f8b2c61a38ed6
* Fix incorrect locking and attempts check in ShadowTree experiment (#52681)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52681
Changelog: [internal]
In the original change I made in D78418504 / https://github.com/facebook/react-native/pull/52645 I made 2 mistakes:
1. Used a lock that would try to re-lock on itself without it being recursive (which would cause a deadlock). I didn't see that because when testing I didn't hit the case where we'd exhaust the options.
2. The `attemps` variable wasn't incremented, so we never left the loop in case of exhaustion.
This propagates a flag to `tryCommit` to indicate we've already locked on the commitMutex_ so we don't need to lock again in that case and increases the counter, fixing the issue.
Reviewed By: cortinico
Differential Revision: D78497509
fbshipit-source-id: 546ccd0c84aed5416ce1aef47d79419b4fe06f66
* Rollout `preventShadowTreeCommitExhaustionWithLocking` in experimental (#52709)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52709
We want to make user for folks in OSS to try
`preventShadowTreeCommitExhaustionWithLocking`. Therefore I'm updating the OSS
release channel for this flag to experimental.
Changelog:
[Internal] [Changed] - Rollout `preventShadowTreeCommitExhaustionWithLocking` in experimental
Reviewed By: rubennorte
Differential Revision: D78558655
fbshipit-source-id: 02a9d216c7b2f8f7bdc1340213f82b70c5692dc7
---------
Co-authored-by: Rubén Norte <rubennorte@meta.com>
Summary:
When switching between debug/release we run a small script to make sure to copy the correct version of the RNDeps xcframework.
This script was missing a resolve function that fixed up some path issues that we do when installing in the podspec.
## Changelog:
[IOS] [FIXED] - Fixed issue with RNDeps release/debug switch failing
Pull Request resolved: https://github.com/facebook/react-native/pull/52664
Test Plan:
- Create new RN App
- Install pod with prebuilt deps
- Build (success)
- Switch to release
- Build (success)
Reviewed By: cortinico
Differential Revision: D78481590
Pulled By: cipolleschi
fbshipit-source-id: 2d02b0bc55e8aef6f3fafb4f7aa193c4cf00414e
Summary:
When switching between release/debug we're running a script to copy the correct xcframework. This script for the React-Core prebuilts was not part of the package.json file.
This caused the build to fail after trying to switch from debug -> release.
## Changelog:
[IOS] [FIXED] - Fixed missing script for resolving prebuilt xcframework when switching between release/debug
Pull Request resolved: https://github.com/facebook/react-native/pull/52663
Test Plan:
- Create new RN App
- Install pod with prebuilt deps and core
- Build (success)
- Switch to release
- Build (success)
Reviewed By: cortinico
Differential Revision: D78481302
Pulled By: cipolleschi
fbshipit-source-id: 1c7181e63219098ae140d77ff1cb2c0c9b9642e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52625
Changes `react-native/babel-preset` so that by default, `hermes-parser` is configured with `reactRuntimeTarget: "19"`. This changes the compiled output of Component Syntax to not use `forwardRef` when a `ref` prop is present.
Additionally, this adds a new preset option property, `hermesParserOptions`. This object allows users of `react-native/babel-preset` to supply overrides for any `hermes-parser` options.
Changelog:
[General][Changed] - Configures `react-native/babel-preset` to target React 19 by default, meaning Component Syntax will not compile to `forwardRef` calls when a `ref` prop is present.
[General][Added] - Added support to `react-native/babel-preset` for a `hermesParserOptions` option, that expects an object that enables overriding `hermes-parser` options.
Reviewed By: SamChou19815
Differential Revision: D78383269
fbshipit-source-id: 1e6b66b9bfbeaf8a06fdc39031cb6de7e921765f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52530
This PR fixes two issues with `display: contents` implementation:
1. When a node with `display: contents` set is a leaf, it won't be cloned after the initial tree is built. The added test case covers this scenario.
2. It was possible for the subtree of `display: contents` nodes not to be cloned during layout. I don't have a minimal reproduction for this one, unfortunately. It was discovered in the Expensify app: https://github.com/Expensify/App/issues/65268, along with a consistent reproduction. In that specific case, it seems to be heavily tied to `react-native-onyx`, which is a state management library.
Changelog: [GENERAL][FIXED] - Fixed nodes with `display: contents` set being cloned with the wrong owner
X-link: https://github.com/facebook/yoga/pull/1826
Reviewed By: adityasharat, NickGerleman
Differential Revision: D78084270
Pulled By: j-piasecki
fbshipit-source-id: eb81f6d7dcd1665974d07261ba693e2abea239bb
Summary:
Instead of returning when creating the list of header files from our podspecs, we now call `continue`. This is a bug that causes all subsequent globs in the header file list to be omitted after the first omitted glob.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fixed premature return in header file generation from podspec globs
Pull Request resolved: https://github.com/facebook/react-native/pull/52490
Test Plan: Run prebuild scripts and verify that React-Fabric podspec headers are included in the resulting xcframework.
Reviewed By: mdvacca
Differential Revision: D78012399
Pulled By: cipolleschi
fbshipit-source-id: 2d334f4f7ff966ea4c778786a7056e13a255a708
Summary:
This PR (initially created for edge-to-edge opt-in support, rebased multiple times) fixes the `Dimensions` API `window` values on Android < 15, when edge-to-edge is enabled.
Currently the window height doesn't include the status and navigation bar heights (but it does on Android >= 15):
<img width="300" alt="Screenshot 2025-06-27 at 16 23 02" src="https://github.com/user-attachments/assets/c7d11334-9298-4f7f-a75c-590df8cc2d8a" />
Using `WindowMetricsCalculator` from AndroidX:
<img width="300" alt="Screenshot 2025-06-27 at 16 34 01" src="https://github.com/user-attachments/assets/7a4e3dc7-a83b-421b-8f6d-fd1344f5fe81" />
Fixes https://github.com/facebook/react-native/issues/47080
## Changelog:
[Android] [Fixed] Fix `Dimensions` `window` values on Android < 15 when edge-to-edge is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/47554
Test Plan:
Run the example app on an Android < 15 device.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77547628
Pulled By: alanleedev
fbshipit-source-id: 9d841f642d5b7ef3294dfbf3868137087a672ad6
Summary:
This change tries to use the prebuilds we build in CI i other iOS jobs to speed-up the iOS CI
bypass-github-export-checks
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/52531
Test Plan:
Build rntester using prebuilds:
```
# after downloading the prebuilds from CI and unzipping them
export HERMES_ENGINE_TARBALL_PATH=~/Downloads/hermes-ios-Debug.tar.gz
export RCT_USE_LOCAL_RN_DEP=~/Downloads/reactnative-dependencies-debug.tar.gz
export RCT_TESTONLY_RNCORE_TARBALL_PATH=~/Downloads/React.xcframework.tar.gz
USE_FRAMEWORKS=dynamic bundle exec pod install
open RNTesterPods.xcworkspace
```
And then build from Xcode.
Reviewed By: rshest
Differential Revision: D78158734
Pulled By: cipolleschi
fbshipit-source-id: 43cbb66bd44fa621292b69de0dadde5ed20c4574
Summary:
This PR fixes the following build error while trying to build `react-native@0.81.0-rc.0` app with `react-native-screens@4.10.0` installed using react-native prebuilds (AAR) due to a missing `react/renderer/bridging/bridging.h` file in `prefab/modules/` inside `react-android-0.81.0-rc.0-debug.aar`.
```
In file included from /Users/tomekzaw/RNOS/react-native-reanimated/node_modules/react-native-screens/android/src/main/cpp/NativeProxy.cpp:2:
In file included from /Users/tomekzaw/.gradle/caches/8.14.1/transforms/75e7f8f7b5ef763e687a16737daf01b6/transformed/react-android-0.81.0-rc.0-debug/prefab/modules/reactnative/include/react/fabric/Binding.h:12:
In file included from /Users/tomekzaw/.gradle/caches/8.14.1/transforms/75e7f8f7b5ef763e687a16737daf01b6/transformed/react-android-0.81.0-rc.0-debug/prefab/modules/reactnative/include/react/fabric/FabricUIManagerBinding.h:22:
/Users/tomekzaw/.gradle/caches/8.14.1/transforms/75e7f8f7b5ef763e687a16737daf01b6/transformed/react-android-0.81.0-rc.0-debug/prefab/modules/reactnative/include/react/renderer/uimanager/primitives.h:14:10: fatal error: 'react/renderer/bridging/bridging.h' file not found
14 | #include <react/renderer/bridging/bridging.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
ninja: build stopped: subcommand failed.
```
## Changelog:
[ANDROID] [CHANGED] - Expose `react_renderer_bridging` headers via prefab
Pull Request resolved: https://github.com/facebook/react-native/pull/52529
Reviewed By: cipolleschi
Differential Revision: D78092428
Pulled By: cortinico
fbshipit-source-id: de8208ae7545201f600c277a0c8907575c310c58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52528
This was a breaking change that is currently breaking `react-native-safe-area-context` so we can't ship it as it is, especially because all the apps in OSS will be affected by this.
Changelog:
[General] [Changed] - Revert breaking change due to the removal of `ShadowNodeTraits::Trait::DirtyYogaNode`
Original commit changeset: 869e81f0ae00
Original Phabricator Diff: D75324251
Reviewed By: huntie
Differential Revision: D78085848
fbshipit-source-id: f7fcc5e33d59cc966a4ee88dfdbedca4f4c580e0
Summary:
Fixes #T228219721
This commit adds the debug/release switch script like we have for rn deps and hermes for react-core prebuilt:
- Added script: replace-rncore-version-js
- Inserted script into React-Core-prebuilt podspec
- Updated rncore.rb with correct filenames
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - add release/debug switch script for React-Core-prebuilt
Pull Request resolved: https://github.com/facebook/react-native/pull/52498
Test Plan: Run in RNTester and switch between release/debug
Reviewed By: rshest
Differential Revision: D78012917
Pulled By: cipolleschi
fbshipit-source-id: 71cad23cd41484a8253fc89d5dce8653649657a0
Summary:
When using prebuilts the USE_FRAMEWORKS setting is not really relevant for the React Native code, since there will not be any source code to build frameworks for - and because we already have a framework for the code in React.XCFramework.
This commit adds a new command to the React Native podspecs like we did with the ReactNativeDependencies framework. The method is called `add_rncore_dependency` and it does nothing when building from source - but when linking with the React.XCFramework it explicitly adds linking with the framework.
In addition there are a few places in the ruby code where we check for the USE_FRAMEWORK value and changes some settings - where needed this commit will add a separate check to ensure we're building from source when making these changes.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Added support for using USE_FRAMEWORKS with prebuilt React Native Core
Pull Request resolved: https://github.com/facebook/react-native/pull/52489
Test Plan:
RNTester:
- Builds without USE_FRAMEWORKS as before with/without prebuilt
- Builds with USE_FRAMEWORKS=dynamic as before with source - and now also with prebuilt code.
- Same goes for the static variant.
Reviewed By: mdvacca
Differential Revision: D78012332
Pulled By: cipolleschi
fbshipit-source-id: ea942738ae52b9dceae48fb78a5026f04b7545b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52513
We bumped the requirement for cocoapods to use Xcode 16.1 or greater.
This job was not update and therefore it failed when releasing 0.81.0-rc.0.
This change should fix it and it should be cherry picked in the release branch too.
By default, the macos executor in github actions are using Xcode 15.2
## Changelog
[Internal] -
Reviewed By: cortinico, fabriziocucci
Differential Revision: D78008316
fbshipit-source-id: 4d05233ca3b936cf128400030328124c453963ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52512
The way Maven works is that the artifacts are uploaded and available way before the browsing UI will allow us to browse them.
By trying to download the `.pom` file instead of checking for the browsing website to be visible, we can shave some minutes during the release
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D78008635
fbshipit-source-id: 96516163628d6d25db385d996a11b4af78db764a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52514
As per title, this change add the `ENTERPRISE_REPOSITORY` env variable so that users can use their owm maven mirror to consume artifacts rather than the official url.
This is helpful as:
- we can reduce the traffic toward maven central
- companies can speed up their builds by relying on local/closer replicas
## Changelog:
[iOS][Added] - Add the `ENTERPRISE_REPOSITORY` env variable to cocopaods infra
Reviewed By: cortinico
Differential Revision: D78011424
fbshipit-source-id: 24b83b4866095d7fe3318362afc5075b99b146e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52399
I'm raising the deprecation warnings for those methods that are using legacy arch.
Previously the `DeprecatedInNewArchitecture` was not generating warnings for user in their builds, while now the Kotlin's/Java's `DeprecatedInNewArchitecture` it will.
Changelog:
[Android] [Changed] - Introduce more deprecation warnings for Legacy Arch classes
Reviewed By: mdvacca
Differential Revision: D77736713
fbshipit-source-id: bc21729ed8253d3ec6b6a40577bcd76622c3f8a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52402
changelog: [internal]
Mark ShadowNode::ListOfShared as deprecated and replace most usages throughout the React Native renderer codebase with the explicit std::vector<std::shared_ptr<const ShadowNode>> type. This improves code clarity by making the container type explicit rather than relying on a type alias.
Reviewed By: christophpurrer
Differential Revision: D77651676
fbshipit-source-id: 8c4bd9b8cbbe467384b947ef9e7a4524f2053e36
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52412
Changelog: [Internal]
The sample is from an outdated approach of enabling C++ Modules in RN which is not recommended anymore.
Prefer C++ Turbo Modules if you need to expose / access C or C++ APIs in RN apps:
https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules
It is not included in any RNTester app at this time
Reviewed By: cortinico
Differential Revision: D77770455
fbshipit-source-id: 987c9f2b9ab4145a2f6a724aad12d8473957dbe8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52407
Changelog: [Internal]
The sample is from an outdated approach of enabling C++ Modules in RN which is not recommended anymore.
Prefer C++ Turbo Modules if you need to expose / access C or C++ APIs in RN apps:
https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules
Reviewed By: javache
Differential Revision: D77765443
fbshipit-source-id: 112fef4c1a7e1c567f3c1d471728a1dfc926adc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52388
Changelog: [Internal]
Similar to `AsyncCallback<>` (the foundation of `AsyncPromise`) we should allow `void` Promise types in C++ such as `AsyncPromise<>`
Reviewed By: rbergerjr
Differential Revision: D77712020
fbshipit-source-id: d7360df5cc1b77f1e03e5fb73b0b468f6e3a415b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52456
Remove the last use of a Metro deep import in preparation for making all deep imports semver-private.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D77450110
fbshipit-source-id: de7aa9c1f6b0d281fe8a6c3bd95e721c5bb58c63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52438
Motivation: After some investigation, these make sense as private APIs, and we intend to modify `UriHandler` slightly in order to report blob response body payloads via CDP for Network debugging.
Changelog:
[Android][Removed] - Internalize `NetworkingModule`'s `UriHandler`, `RequestBodyHandler`, and `ResponseHandler` APIs
Reviewed By: cortinico
Differential Revision: D77799144
fbshipit-source-id: 20c36f52a900830091a253ab9917832c30b31d31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52436
Reordered the different property types in the switch/case to group similar outputs together.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D77799101
fbshipit-source-id: 5b7c6d188e9ffa0f1e41f44f82f438afeda04d74
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52439
Users should not be passing true/false values for the 3 params in the `load()` method. The app template already uses the no param overload.
I'm deprecating it so it can go in 0.81.
Changelog:
[Android] [Changed] - Deprecate the DefaultNewArchitectureEntryPoint.load(Boolean, Boolean, Boolean)
Reviewed By: rubennorte
Differential Revision: D77739268
fbshipit-source-id: c901d1ed2e9623b0fa39f4e2d79f25404c284b8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52427
Adds and wires up a minimal implementation of `PerformanceResourceTiming` on the JS side. This materialises D74245441 in user space.
When all feature flags are enabled, network requests can now be observed from JS via `PerformanceObserver`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D75062713
fbshipit-source-id: 06523e70f57feaaa53432ef21fa92676d1e90360
Summary:
reverting Refactor ViewManagerInterfaces codegen to generate kotlin classes because of warning in OSS, we will reland after 0.81 cut
Changelog: [Android][Breaking] - Revert of Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: lenaic, mlord93
Differential Revision: D77759777
fbshipit-source-id: c24b216b231cdc53296d8c9fca8d789d80daa596
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52393
## Changelog:
[General][Deprecated] - ShadowNode::Shared is now deprecated. Use `std::shared_ptr<const ShadowNode>` instead.
- Mark ShadowNode::Shared as deprecated in ShadowNode.h
- Replace all uses of ShadowNode::Shared with std::shared_ptr<const ShadowNode>.
This continues the systematic effort to remove ShadowNode type aliases in favor of explicit standard library types for improved code clarity and maintainability.
Reviewed By: christophpurrer
Differential Revision: D77650696
fbshipit-source-id: b4769e2a1e39f49d14d5927be105487ecf69fa3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52405
This field has been deprecated since RN 0.77, we can safely remove it ahead of the branch cut.
Changelog:
[Android] [Removed] - Remove deprecated `isStartSamplingProfilerOnInit` from `DeveloperSettings`
Reviewed By: mdvacca, javache
Differential Revision: D77734913
fbshipit-source-id: 231ecb360921d48ec941a3a214e73b4b89446c13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52395
This method was exposed as `public` but there is no need for us to expose it in OSS.
So I'm marking it as internal.
Changelog:
[Internal] [Changed] - Make loadWithFeatureFlags correctly internal
Reviewed By: mlord93, mdvacca, javache
Differential Revision: D77734270
fbshipit-source-id: 34e1d7aaa4a5bf3563c78aad570e2310592bcc77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52382
Changelog: [Internal]
In C++, both `virtual ~CallInvoker() {}` and `virtual ~CallInvoker() = default` can be used to define a virtual destructor. However, they have slightly different implications:
1. `virtual ~CallInvoker() {}`:
* This is the traditional way of defining a virtual destructor.
* It provides an empty implementation for the destructor, which does nothing.
* The compiler will not generate a default implementation, as you've provided one explicitly.
2. `virtual ~CallInvoker() = default`:
* This is a more modern way of defining a virtual destructor (introduced in C++11).
* It tells the compiler to generate a default implementation for the destructor.
* The default implementation will perform the necessary cleanup operations, such as calling the destructors of base classes and member variables.
In general, `= default` is considered better because it:
* Avoids unnecessary code duplication: By letting the compiler generate the default implementation, you avoid duplicating code that's already generated by the compiler.
* Improves maintainability: If the class has member variables or base classes with non-trivial destructors, using `= default` ensures that the correct cleanup operations are performed without requiring manual updates.
* Conveys intent: Using `= default` clearly indicates that the destructor should perform its default behavior, making the code easier to understand.
So, unless you have a specific reason to provide a custom implementation, `virtual ~CallInvoker() = default` is generally the better choice.
Reviewed By: rshest
Differential Revision: D77685932
fbshipit-source-id: 78c81f8e400069ad38d8d7405dafeb0b6db8e67b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52347
We can build an accessibility tree for Talkback by overriding addChildrenForAccessibility of ViewGroup.
With this we just manually build a tree that contains the elements we care about in the order we want.
We also try to keep most of the tree intact so that coopting works properly
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77258926
fbshipit-source-id: 767ebc880a2efbf7934b9e7dee3013dd7822e5ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52297
Doing virtual views is the only way of making it possible to add the host view into the order. This however is too complex for very little gain, we are opting to go for a cleaner solution with the trade off of not being able to add the host view.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77278752
fbshipit-source-id: 709b995f51a9a03f6d07f2e24f8aea21d62d95c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51735
This diff refactors the ViewManagerInterfaces codegen to generate kotlin classes,
As a consequence of this change, there are some ViewManagerInterfaces that have changed their APIs
## Changelog: [Android][Breaking] - Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: javache
Differential Revision: D75719542
fbshipit-source-id: 7e9aa7ccc24e827bd7b6df72b3302e852932e731
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52400
`react-stack-bottom-frame` -> `react_stack_bottom_frame`.
This survives `babel/plugin-transform-function-name`, but now frames
will be displayed as `at Object.react_stack_bottom_frame (...)` in V8.
Checks that were relying on exact function name match were updated to
use either `.indexOf()` or `.includes()`
For backwards compatibility, both React DevTools and Flight Client will
look for both options. I am not so sure about the latter and if React
version is locked.
DiffTrain build for [91d097b2c588a0977a7a10ed12512dc8a34e3a5b](https://github.com/facebook/react/commit/91d097b2c588a0977a7a10ed12512dc8a34e3a5b)
Reviewed By: jackpope
Differential Revision: D77601866
fbshipit-source-id: 24ed8713af4bebbaeb7a612333cd79c51b696565
Summary:
This PR (initially created for edge-to-edge opt-in support, rebased multiple times) fixes the `Dimensions` API `window` values on Android < 15, when edge-to-edge is enabled.
Currently the window height doesn't include the status and navigation bar heights (but it does on Android >= 15):
<img width="300" alt="Screenshot 2025-06-27 at 16 23 02" src="https://github.com/user-attachments/assets/c7d11334-9298-4f7f-a75c-590df8cc2d8a" />
Using `WindowMetricsCalculator` from AndroidX:
<img width="300" alt="Screenshot 2025-06-27 at 16 34 01" src="https://github.com/user-attachments/assets/7a4e3dc7-a83b-421b-8f6d-fd1344f5fe81" />
Fixes https://github.com/facebook/react-native/issues/47080
## Changelog:
[Android] [Fixed] Fix `Dimensions` `window` values on Android < 15 when edge-to-edge is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/47554
Test Plan:
Run the example app on an Android < 15 device.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77547628
Pulled By: alanleedev
fbshipit-source-id: 9d841f642d5b7ef3294dfbf3868137087a672ad6
Summary:
We need to upgrade the targetSdk to 36, which requires ensuring compatibility with the latest Android APIs and addressing any deprecations or behavior changes introduced in this version.
## Changelog:
[Android] [Changed] - Updated targetSdk to 36 in Android.
Pull Request resolved: https://github.com/facebook/react-native/pull/52355
Test Plan:
- Verified that the app builds and runs successfully with targetSdkVersion 36.
- Ran the full suite of unit and instrumentation tests: all tests passed.
- Manually tested key user flows (login, navigation, data sync) on devices running Android 14 (API 34) and emulator with API 36
- Confirmed that there are no runtime crashes or warnings related to `targetSDK` upgrade.
Behavioral guide for migration: https://developer.android.com/about/versions/16/behavior-changes-16
Reviewed By: fabriziocucci
Differential Revision: D77728391
Pulled By: cortinico
fbshipit-source-id: 3f714f900bbeecc56c0cf46c54b4e42c532c8384
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52335
Adds support for `Network.requestWillBeSentExtraInfo` and `Network.dataReceived` CDP events in jsinspector-modern and wires up for iOS.
In particular, `Network.requestWillBeSentExtraInfo` is necessary to populate request headers in the UI.
**End of base Network implementation for iOS**
After this diff, we are spec-complete on all CDP Network methods for our V1, on iOS.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77489476
fbshipit-source-id: 84aa4da9d9fcbdc61eff236fc6bd2136496910a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52334
Adds support for `Network.loadingFailed` in jsinspector-modern and wires up for iOS.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77489477
fbshipit-source-id: dc8156979fe49583819019fa4b88b6eb99dea734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52331
Updates the iOS inputs to `NetworkReporter` to support incremental string data HTTP responses (`Transfer-Encoding: chunked`).
This means that incremental responses, such as Metro bundle requests, can be displayed as previews in React Native DevTools.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77457109
fbshipit-source-id: 00a622dbac97c38e07c67b5ee3661c8d586f6fe1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52332
Adds support for the [`Network.getResponseBody`](https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-getResponseBody) CDP event in `jsinspector-modern` and configures this for iOS. This enables us to populate the "Preview" and "Response" tabs in the React Native DevTools Network panel.
This is integrated with `RCTNetworking.mm` to support synchronously received `text` or `blob` data types, with incremental response support added next in D77457109.
**Implementation notes**
- Adds a new `BoundedRequestBuffer` construct to safely buffer response previews at a max memory size.
- `RCTNetworking` will always call `maybeStoreResponseBody` (when feature flag enabled), but is unaware whether there is an active CDP debugging session with network support or not.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D74319394
fbshipit-source-id: c9dbb44551c15d1b1a7cce56b35bf829f8a99dc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52380
Apps that rely support focus in FlatList rendered items are missing out on a FlatList optimization that defers rendering for offscreen content updates.
For example, on Android, if you focus and smooth scroll an item into view, the onScroll event will fire first. For most sufficiently large virtualization windows, the next render will be delayed by the render batch timeout as most materialization of virtualized views is not treated as a high pri render.
However, this batch / timeout mechanism isn't being used for cell render updates that occur as a result of a focus change.
This change adds the same timeout mechanism used for scroll events. In most cases, the view that is focused is in the viewport, and the extra rendering needed is already scheduled (or executed with high priority if needed) when the onScroll event is processed.
In cases where the focus change occurs outside the viewport, most platforms will want to do some kind of "bring into view" anyway, and the same applies - onScroll will take care of scheduling the cell rendering priority.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D77681274
fbshipit-source-id: 1ade377e513eca21338a380ff9299dd410606aec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52358
Another class going from Java to Kotlin.
This is quite involved due to the amount of Raw generics we were using so I'd appreaciate a couple of further eyes here.
Changelog:
[Android] [Changed] - Convert UIManagerModuleConstantsHelper to Kotlin
Reviewed By: mdvacca, javache
Differential Revision: D77589975
fbshipit-source-id: 477c1e2a8dfd31db60047fd1252f6d47c177f5c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52378
This adds a Gradle property called `exclusiveEnterpriseRepository`
that users can set in their `android/gradle.properties` as such:
```diff
# Use this property to enable or disable the Hermes JS engine.
# If set to false, you will be using JSC instead.
hermesEnabled=true
+exclusiveEnterpriseRepository=https://my.internal.proxy.net/
```
This will remove all the existing Maven repositories and only use the internal mirror they have.
Changelog:
[Android] [Added] - RNGP - Add support for `exclusiveEnterpriseRepository` to specify an internal Maven mirror.
Reviewed By: mdvacca
Differential Revision: D77667573
fbshipit-source-id: 835004d2ae7aa4e250b6f7a88a41918b573f5bd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52387
I would like to grab this in a subclass but unfortunately can't. It is kinda jank since this is a val obtained via reflection, but I figure this is better than copy and paste. I think that I could also expose a function that uses this scroller the way I want it to. Let me know if there are strong objections here
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D77684599
fbshipit-source-id: 6f02c1da5135c1cf34fa1483542e06bf8f0be75e
Summary:
This change fixes an issue on iOS where gradients that fade to a transparent color-stop appear dark or "muddy." The fix ensures that the color's hue is preserved during the transition, matching the behavior on Android and web.
### The Problem
When creating a gradient on iOS (e.g., linear-gradient(red, transparent)), the transparent keyword is treated as transparent black (rgba(0,0,0,0)). The `CAGradientLayer` on iOS then interpolates all color channels linearly, causing the red, green, and blue components of the start color to fade to 0. This transition through black results in an undesirable dark or "muddy" appearance in the middle of the gradient.
## Changelog:
[IOS][FIXED] - Gradient interpolation for transparent colors
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52249
Test Plan:
Checkout `LinearGradient` example in RNTester, checkout the newly added transparent color transition example, it should render same on android and iOS.
| Before | After |
| --- | --- |
| <img src="https://github.com/user-attachments/assets/c0bb54ad-ed0e-4a80-b37f-0458af0f1f77" width="300"> | <img src="https://github.com/user-attachments/assets/02da921a-bd0e-45c1-881c-cf6460d5ed43" width="300"> |
| `linear-gradient(to right, red, transparent)` transitions to black on iOS, creating a dark effect. | The gradient correctly fades the red color's alpha channel to zero |
Reviewed By: javache
Differential Revision: D77312194
Pulled By: NickGerleman
fbshipit-source-id: 053df8e44f52cd22a3f28fd01f583f7d03c66af5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52386
Enum `values()` function makes a copy of an underlying array on each call. This happens in a hot path, and seems to show up during profiling. Let's cache it.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77623705
fbshipit-source-id: 5a33425822f477f63fe104ca9e5ed474385a2022
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52385
This replaces `buildSpannableFromFragmentsOptimized()` with a more optimized version. There are a couple main changes.
1. We don't need a complicated structure around ordering, and span priority, that made its way from the Java ShadowNode logic. AttributedString already ensures there are no overlapping attributes per fragment.
2. `SpannableStringBuilder` is a complicated text-editor style data structure, optimized to allow text content to be modified, and spans re-applied. We can use a much lighter `SpannableString`, on top of the ahead-of-time known text content, which is faster, and saves around 500 bytes per string (and prepared layout). If we assign this to an `EditText`, which later gets edited, Android will copy it to a `SpannableStringBuilder`.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77622848
fbshipit-source-id: 69bbac86e1f0fd4a15dab6bc279cca305f2a53ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52372
This is just a follow-up on top D77025333 to make sure that the links in the blog posts and the GitHub releases keep working.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D77654056
fbshipit-source-id: a1c6df44ebee058dd5b59e5b6a60c7c1e060e52c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52370
This is just a patch bump of Gradle ahead of the 0.81 branch cut.
Changelog:
[Android] [Changed] - Bump Gradle to 8.14.2
Reviewed By: fabriziocucci
Differential Revision: D77601121
fbshipit-source-id: b2fdc8b022f2ab43997f412c77e0c924c01f1a5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52369
Tiny fix where the system status bar elements were no longer visible under Android edge-to-edge.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D77653633
fbshipit-source-id: 1275a0de6665a6ef4599166fb205865cd581bb41
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52359
This is needed ahead of the 81 branch cut.
Changelog:
[Internal] - Bump all packages to 0.81.0-main
Reviewed By: huntie
Differential Revision: D77602196
fbshipit-source-id: 1b52a7d1577783d72aba8d20f98032f29ffcc7df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52357
Changelog: [Internal]
Adds a hyper-minimal build script using `electron/packager` that produces custom binaries for the experimental React Native DevTools standalone shell. The main user-facing benefit of this is replacing the Electron name and icon with our own branding.
NOTE: `electron/packager` is designed to include the application code in the resulting binary. This is arguably overkill for us - the current launch model of `electron src/electron/index.js` is actually wholly sufficient for what we need - but I decided to go with the grain of the available tooling for simplicity.
Icon design courtesy of huntie. 🙏
Reviewed By: huntie
Differential Revision: D77591742
fbshipit-source-id: a968465df4f54fba54c874b6300788e151600ed7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52365
Adds type imports autofix support and pass `fb_internal` paths in react native deep imports eslint rule. The rule fixes imports with all matched types with static API mapping to prevent splits.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77445445
fbshipit-source-id: cd5b75b4b3b53792117b8297352dddc4d63dbf70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52345
changelog: [internal]
I would like to measure impact of D76597973 to get a better understanding of UIKit's rendering.
Reviewed By: yungsters
Differential Revision: D77542666
fbshipit-source-id: 4c2de4f36d2b374d83df934dd3a98d01b24f487f
Summary:
This PR connects breaking change detection with a danger bot. The action takes snapshot from main branch and from the PR as inputs to`diff-api-snapshot` (saved in runner temp directory).
## Changelog:
[Internal]
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52045
Reviewed By: huntie
Differential Revision: D76735630
Pulled By: coado
fbshipit-source-id: 9208117340c1e0bf10d58b67892727717d22e62f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52353
This diff aligns breaking change detection script with new snapshot format. It compares hashes to determine if the API changed for each specifier.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77377762
fbshipit-source-id: e1c69692ace389fb08ae9470b9f9631e53834206
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52342
This diff deletes `public-api-test` for detecting changes in public API. It is replaced with public API snapshot validation (in D76340729) for better detection and understanding of changes that influence external interfaces.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77531763
fbshipit-source-id: a8ef2b6f52fa6efb5b312598ea3e4746fc51e4ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52352
This diff adds excution of `yarn build-types --validate` to run RN JS API snapshot validation on CI.
### Motivation
Detect react-native public API changes before they land.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D76340729
fbshipit-source-id: 10c465418e0ba4eb05cf557a16119f9756843d9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52343
This diff commits our V2 JavaScript API snapshot for React Native.
This is a new format and workflow that replaces the previous `public-api-test` Jest test.
Please look at the file header for up-to-date instructions on updating the API snapshot.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D77532617
fbshipit-source-id: d5faae815aa5071b0f472fcb02318b73772b11cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52268
Ships the feature flag introduced in https://github.com/facebook/react-native/pull/51719 to fix crahes that result from shadowed animated style values.
Changelog:
[General][Changed] - Animated now always flattens `props.style`, which fixes an error that results from `props.style` objects in which `AnimatedNode` instances are shadowed (i.e. flattened to not exist in the resulting `props.style` object).
Reviewed By: javache
Differential Revision: D77314904
fbshipit-source-id: b442d0256aee7a8925e28c7e87aee5e0a3f39425
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52354
These should no longer be needed as `ReactNativeFeatureFlags` handles the missing native module gracefully.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D77365271
fbshipit-source-id: 92c6789b2175f24c79838118f681107a43c9ff0a
Summary:
X-link: https://github.com/facebook/yoga/pull/1823
Pull Request resolved: https://github.com/facebook/react-native/pull/52348
Fixes https://github.com/facebook/yoga/issues/1819
Yoga has a fast path when measuring a node, if it thinks it knows its dimensions ahead of time.
This path has some eroneous logic, to set both axis to owner size, if *either* will evaluate to zero, while having an `YGMeasureModeAtMost`/`FitContent` constraint. This means that if a node is given a zero width, and Yoga later measures with with `FitContent`, its height will become the maximum allowable height, even if it shouldn't be that large.
We can fix this, by only allowing if both axis are this fixed case, instead of just one.
This bug has existed for about a decade (going back to at least D3312496).
Changelog:
[General][Fixed] - Fix possible invalid measurements with width or height is zero pixels
Reviewed By: yungsters
Differential Revision: D76851589
fbshipit-source-id: 6f5a0e6beccc51f591726c9e83e9b90f3350ed0f
Summary:
Static code analysis reports several weak warnings, many of which seem to be leftovers after Kotlin migration. This PR addresses quite a few:
- [Accessor call that can be replaced with property access syntax](https://www.jetbrains.com/help/inspectopedia/UsePropertyAccessSyntax.html)
## Changelog:
[INTERNAL] - Kotlin: fix static code analysis weak warnings (6/n)
Pull Request resolved: https://github.com/facebook/react-native/pull/52338
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: NickGerleman
Differential Revision: D77504913
Pulled By: cortinico
fbshipit-source-id: 62661ba6adafb7893ce27811357020966d5ea4c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52346
This is bypassing the mutex, and potentially not thread-safe.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D77541041
fbshipit-source-id: f97415d066786864806836768dbce2d5e68487ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52341
The setter for `createNewDialog` is now wrong (after D76834213).
If the `createNewDialog` has been set to `true` by any other field, we should respect it and not set it to true/false regardless
(only considering the `isEdgeToEdgeFeatureFlagOn`) property.
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77539533
fbshipit-source-id: a1deaf1f1b856895304e8b73fa5d0c0367e677af
2025-06-30 10:16:55 -07:00
464 changed files with 14098 additions and 14648 deletions
- **Flow:** Publish top-level Flow types for `react-native` ([fbbd20dd63](https://github.com/facebook/react-native/commit/fbbd20dd632acd72d2abe861dd4a0e6e98437cf2) by [@buschco](https://github.com/buschco))
- **Flow:** Fix typo when publishing Flow types for `react-native` ([50667eceb1](https://github.com/facebook/react-native/commit/50667eceb1be4771375d6a3cc2f4e42d4d8aad3a) by [@aswinandro](https://github.com/aswinandro))
### Fixed
- **jest:** Fix missing RefreshControlMock source in Jest preset ([6044e01460](https://github.com/facebook/react-native/commit/6044e01460a065845d4178f0fdc54a601ce4c07e) by [@huntie](https://github.com/huntie))
#### Android specific
- **runtime:** Fix crash on ReactInstance due to null returned for getViewManagerNames ([f6b7bd93d8](https://github.com/facebook/react-native/commit/f6b7bd93d8d0d2095669144c8de438cf64d8e73f) by [@cortinico](https://github.com/cortinico))
- **TurboModules:** Emitting event from turbo module crashes on 32bit android ([36ddf853c3](https://github.com/facebook/react-native/commit/36ddf853c381966645789bc814fc2f6bb4d74cd2) by [@vladimirivanoviliev](https://github.com/vladimirivanoviliev))
## v0.80.0
### Breaking
@@ -317,3 +333,879 @@
- **Text:** Correctly announce "link" on nested text if its the entire text element ([bffb414291](https://github.com/facebook/react-native/commit/bffb414291cfbd3d6e3e51448dd68b7bddddf658) by [@joevilches](https://github.com/joevilches))
- **Text:** Selection range not respected when changing text or selection when selection is forced ([d32ea66e6a](https://github.com/facebook/react-native/commit/d32ea66e6a945dd84092532401b265b12d482668) by Olivier Bouillet)
- **TextInput:** Fix TextInput `onContentSizeChange` event being dispatched only once on iOS on the new architecture ([5fd5188172](https://github.com/facebook/react-native/commit/5fd51881727b2d86f87abf04db032940ac0ec8c4) by [@j-piasecki](https://github.com/j-piasecki))
"description":"Package that includes native module exapmle, native component example, targets both the old and the new architecture. It should serve as an example of a real-world OSS library.",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.