Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51949
This code is no longer necessary now that JSC support is offered via
https://github.com/react-native-community/javascriptcore
Instructions for users on how to continue using JSC are available in the README of such library.
Changelog:
[Android] [Removed] - Remove 1st party JSC support
Reviewed By: javache
Differential Revision: D76420382
fbshipit-source-id: f8e61556bb02fe4d5b34f89b40f8e5e38ac1c8d6
Summary:
When trying to implement e2e tests using maestro in a large app I ran into major performance issues. I tracked it down to the generation of recursive accessibility labels.
The maestro iOS driver uses [XCUIElement snapshot dictionaryRepresentation](https://developer.apple.com/documentation/xctest/xcuielementsnapshot/dictionaryrepresentation) [here](https://github.com/mobile-dev-inc/Maestro/blob/96e8c9a2be3430be991c13d033486d52d2001334/maestro-ios-xctest-runner/maestro-driver-iosUITests/Routes/Handlers/ViewHierarchyHandler.swift#L234) to get a representation of the view hierarchy. The problem is that will query the accessibilityLabel for every single view, starting from the root of the app. It goes without saying that this is extremely slow since it traverses the view hierarchy, executing a recursive function on each one.
I think the only way to fix this is to avoid generating these recursive labels when not needed. From my understanding these should only be needed for accessible views.
## Changelog:
[IOS] [CHANGED] - Only generate recursive accessibility label for accessible elements
Pull Request resolved: https://github.com/facebook/react-native/pull/51988
Test Plan:
- Tested using VoiceOver in RN tester to make sure it works exactly the same.
- Tested in an app using Maestro to make sure this fixes the performance issue.
- Tested in RNTester running Maestro e2e test by creating a larger view hierarchy to make the problem more apparent, and simulate a real app. Using [this code](https://gist.github.com/janicduplessis/9f6b302d92b4e22ff5e8462a8a84e237) in RNTesterAppShared.js
Before:
```
❯ yarn e2e-test-ios
yarn run v1.22.22
$ ./scripts/maestro-test-ios.sh
Waiting for flows to complete...
[Passed] flatlist (14s)
[Passed] text (28s)
[Passed] modal (16s)
[Passed] image (8s)
[Passed] button (10s)
[Passed] legacy-native-module (32s)
[Passed] pressable (32s)
[Passed] new-arch-examples (35s)
8/8 Flows Passed in 2m 55s
✨ Done in 180.26s.
```
After:
```
❯ yarn e2e-test-ios
yarn run v1.22.22
$ ./scripts/maestro-test-ios.sh
Waiting for flows to complete...
[Passed] flatlist (7s)
[Passed] text (15s)
[Passed] modal (10s)
[Passed] image (4s)
[Passed] button (6s)
[Passed] legacy-native-module (16s)
[Passed] pressable (16s)
[Passed] new-arch-examples (17s)
8/8 Flows Passed in 1m 31s
✨ Done in 97.53s.
```
Reviewed By: christophpurrer, joevilches
Differential Revision: D76581949
Pulled By: cipolleschi
fbshipit-source-id: 0689c7d43a0c865572c4ee5ea32ee9b2dcb33ad5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51986
"{}" defaults to false on C++ but the prop is not initialized which means that if accessibilityEnablesUserInteraction is set to false it will not be applied on first render. setting the default to true fixes that issue
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D76532158
fbshipit-source-id: 51cba8b89eb239e01db985d412dd2b19e482f068
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51979
Fix type checking that was left out from the last diff; D73224138
We should unify the type checking so remove uses of `java.lang.Boolean` and just use Kotlin version of `Boolean`.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D76523674
fbshipit-source-id: 293ae5998c78c98a20c7d6cf962ab7b19087fd9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52048
This diff exports types defined in RNCodegen to be used by other codegens
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D76472492
fbshipit-source-id: fa236a254a9a4211d2e00ace436f55978a262a76
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52041
After changing the publishing logic on Maven, the download logic for the artefacts published in a Snapshot was broken, because Maven does not support the redirect anymore.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76725418
fbshipit-source-id: 8bad88915d9bad96355a048486972a55f232d109
Summary:
Static code analysis reports numerous unused symbols across the codebase, which accounts for several static code analysis warnings. I've cleaned up some of them (not all of them because many of them are false positives from testing files)
The cleaned-up symbols are mostly private and from internal classes, so this should not impact users (unless they are used internally at Meta – in that case, let me know so I can revert accordingly)
## Changelog:
[INTERNAL] - Kotlin: clean up some unused symbols
Pull Request resolved: https://github.com/facebook/react-native/pull/52029
Test Plan:
```sh
yarn test-android
yarn android
```
Reviewed By: javache
Differential Revision: D76722313
Pulled By: cortinico
fbshipit-source-id: 8c7dfe204fa7c457b7484a7edd120ae45e1d604d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52035
Fixes https://github.com/facebook/react-native/issues/52014
Some OSS library is still returning null for `getViewManagerNames` especially if they're
implementing the `ViewManagerOnDemandReactPackage` in Java.
I'm adding a try-catch here so that we prevent the NPE for those scenarios.
Changelog:
[Android] [Fixed] - Fix crash on ReactInstance due to null returned for getViewManagerNames
Reviewed By: javache
Differential Revision: D76723826
fbshipit-source-id: cc159dee389257c6877b03a67840a45ee5bec165
Summary:
The OSS CI for iOS is broken because of a couple of commit that landed:
- Commit 05a61e8161 : dynamic frameworks are broken
- Commit abc8fe1c92 : pod donwload is broken
This change fixes both of them
## Changelog:
[Internal] - Fix OSS CI
Pull Request resolved: https://github.com/facebook/react-native/pull/52042
Test Plan:
Tested locally by building RNTester with Dynamic frameworks
```
USE_FRAMEWORKS=dynamic bundle exec pod install
```
Reviewed By: rshest, lenaic, GijsWeterings
Differential Revision: D76730331
Pulled By: cipolleschi
fbshipit-source-id: 71cca1f50763d24773dedcd8267130df261b01dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52012
changelog: [internal]
On iOS, once a prop on a view is controlled by animated, the control is never released to Fabric or React. That's why it is important to use direct manipulation to commit even final value.
Reviewed By: lenaic
Differential Revision: D76601913
fbshipit-source-id: ea02219e158f28977018b34ac7152b899723b35a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52033
This change fixes the download of the artefacts for the nightlies of Hermes and React Native Dependencies after we changed the publishing logic for Maven
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76723289
fbshipit-source-id: 6b0ea6a6c35125e6fb03cecc6be893bd02abdad8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51946
This change simplified the setp disallowing to use JSC from core.
As a side effect, it simplified the setup by always falling back to hermes if the users decides not to use the third party JSC
## Changelog:
[iOS][Removed] - remove the option to use JSC from core
Reviewed By: cortinico
Differential Revision: D76342625
fbshipit-source-id: c925ab4fab1e171e289a1c5f75890c92da1b3f08
Summary:
I am not sure exactly why, but I've been getting this error when running RNTester on iOS, when it tries to build hermesc from source. We're clearing the env using `env -i` which seems to cause the issue. If I add PATH to the env we set then it builds fine.
```
++ hermesc_dir_path=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine/build_host_hermesc
++ shift
++ jsi_path=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/../../react-native/ReactCommon/jsi
+++ xcode-select -p
++ SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
++ env -i SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk /opt/homebrew/bin/cmake -S /Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine -B /Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine/build_host_hermesc -DJSI_DIR=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/../../react-native/ReactCommon/jsi
CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
Command PhaseScriptExecution failed with a nonzero exit code
```
## Changelog:
[INTERNAL] [FIXED] - Fix RNTester hermesc build issue on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/51989
Test Plan: Build RN tester locally
Reviewed By: cortinico
Differential Revision: D76606335
Pulled By: cipolleschi
fbshipit-source-id: f442b77aefb3afacd6d9fb1f3d515b8d63c526ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52020
Aligns the type exports of `ReportFullyDrawnView` across platforms, so that they are resilient to any changes made to `View` itself.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D76638685
fbshipit-source-id: 612b2bcd76e70751aec691a24f31beca453cea35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52016
Upgrade the React Native monorep to use `eslint-plugin-react-hooks@6.1.0-canary`, which includes support for Flow's Component Syntax.
This does not affect production users of `eslint-config-react-native`.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D76627448
fbshipit-source-id: 19e95e5d7f1bcd4fb6bead4e94d268d0c36a4817
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51425
# Problem
React native's new architecture will allow components to do sync render/events. That means they'll makes synchronous dispatches from main thread to the js thread, to capture the runtime so that they can execute js on the main thread.
But, the js thread already as a bunch of synchronous calls to the main thread. So, if any of those js -> ui sync calls happen concurrently with a synchronous render, the application will deadlock.
This diff is an attempt to mitigate all those deadlocks.
## Context
How js execution from the main thread works:
* Main thread puts a block on the js thread, to capture the js runtime. Main thread is put to sleep.
* Js thread executes "runtime capture block". The runtime is captured for the main thread. The js thread is put to sleep.
* Main thread wakes up, noticing that the runtime is captured. It executes its js code with the captured runtime. Then, it releases the runtime, which wakes up the js thread. Both the main and js thread move on to other tasks.
How synchronous js -> main thread calls work:
* Js thread puts a ui block on the main queue.
* Js thread goes to sleep until that ui block executes on the main thread.
## Deadlock #1
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime to be captured
**JS thread**: execute ui code synchronously:
* Js thread schedules a block on the ui thread
* Js thread then goes to sleep, waiting for that block to execute.
**Result:** The application deadlocks
| {F1978009555} | {F1978009612} |
## Deadlock #2
**JS thread**: execute ui code synchronously:
* Js thread schedules a block on the ui thread
* Js thread then goes to sleep waiting for that block to execute.
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime to be captured
**Result:** The application deadlocks
| {F1978009690} | {F1978009701} |
# Changes
This diff attempts to fix those deadlocks. How:
* In "execute ui code synchronously" (js thread):
* Before going to sleep, the js thread schedules the ui work on the main queue, **and** it posts the ui work to "execute js now".
* In "execute js now" (main thread):
* This diff makes "execute js now" stateful: it keeps a "pending ui block."
* Before capturing the runtime, the "execute js now" executes "pending ui work", if it exists.
* While sleeping waiting for runtime capture, "execute js now" can wake up, and execute "pending ui work." It goes back to sleep afterwards, waiting for runtime capture.
## Mitigation: Deadlock #1
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime capture
**JS Thread**: execute ui code synchronously:
* Js thread puts its ui block on the ui queue.
* ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up.
* Js thread goes to sleep.
The main thread wakes up in "execute js now":
* Main thread sees that a "pending ui block" is posted. It executes the "pending ui block." The block, also scheduled on the main thread, noops henceforth.
* Main thread goes back to sleep, waiting for runtime capture.
* The js thread wakes up, moves on to the next task.
**Result:** The runtime is captured by the main thread.
| {F1978010383} | {F1978010363} | {F1978010371} | {F1978010379} |
## Mitigation: Deadlock #2
**JS Thread**: execute ui code synchronously:
* Js thread puts its ui block on the ui queue.
* ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up.
* Js thread goes to sleep.
**Main thread**: execute js now
* Main thread sees that a "pending ui block" is posted. It executes the "pending ui block" immediately. The block, also scheduled on the main thread, noops henceforth.
* Js thread wakes up and moves onto the next task.
**Result:** Main thread captures the runtime.
| {F1978010525} | {F1978010533} | {F1978010542} |
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74769326
fbshipit-source-id: 854b83ce4e482a4030dc711834ea6c5613091537
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52000
Fixes https://github.com/facebook/react-native/issues/50338
The current JS FPS value is incorrect because the frame skipping logic hasn't been reimplemented in Fabric.
As we're looking into moving this into the performance panel, I've discussed with huntie
and agreed we'll just remove the value for now to don't show inaccurate informations.
Changelog:
[Android] [Changed] - Hide JS FPS on performance overlay as not accurate
Reviewed By: huntie
Differential Revision: D76590909
fbshipit-source-id: 90b0d9c84f9aefa9197243ebb57f4e86107d6c01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52003
Changelog: [Internal]
This is a react common dep check that we can build and run tester.
Reviewed By: christophpurrer
Differential Revision: D76531041
fbshipit-source-id: 0a43fdb91aa61f7e6461ff8a94ea6e2732b55dbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51982
This class should not be accessed externally. I'm making it internal.
On top of this, it was not fully reimplemented on NewArch so is not working consistently.
This is gonna break one library which is unmaintained and not properly udpated to work with NewArch
https://github.com/hannojg/react-native-performance-stats
Changelog:
[Android] [Breaking] - Cleanup and internalize FpsDebugFrameCallback
Reviewed By: huntie
Differential Revision: D76531175
fbshipit-source-id: 25598eb7c1ecf476b69bb6a2f2f8088a57b9fbc2
Summary:
This PR fixes RNTester system bars background color to match the app one (not solid black).
## Changelog:
- [Internal] [Changed] - Fix RNTester app system bars color when edge-to-edge is enforced
Pull Request resolved: https://github.com/facebook/react-native/pull/51929
Test Plan:
https://github.com/user-attachments/assets/8be0b721-6514-408f-81cd-2106ae7a17c4
Rollback Plan:
Reviewed By: javache
Differential Revision: D76352950
Pulled By: alanleedev
fbshipit-source-id: 474a81564570764a597aa995a0677617263338be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51941
Changelog:
[Android][Fixed] - Extract out FBReactNativeSpec's core components including Unimplemented from auto-generated registry
Extracting out `FBReactNativeSpec`'s core components including `UnimplementedNativeView` from auto-generated registry. Using this `libraryName` to skip merging those modules
Reviewed By: RSNara
Differential Revision: D76371796
fbshipit-source-id: 4cfee0fe80a661f159a5f17e0d4abc60f601ea74
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52004
This is necessary because the snapshots are now going to be published on a different repository:
central.sonatype.com.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D76596802
fbshipit-source-id: 424fb1134e41502d53b76209fba325c895c79ba8
Summary:
Static code analysis shows that there are several redundant visibility modifiers across the codebase. These are most likely remnants after making different classes internal.
## Changelog:
[INTERNAL] - Kotlin: clean up redundant visibility modifiers
Pull Request resolved: https://github.com/facebook/react-native/pull/51960
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: javache
Differential Revision: D76503015
Pulled By: cortinico
fbshipit-source-id: e60e7aa141fc35ca2fd76335fbee791c86589e4e
Summary:
We found out that the XCFramework that is generated in CI is missing the headers.
This is happening because we run the setup script, the responsible to prepare the folder structure with the heaeders in the right place, only in the job that builds the slices. However, the headers are copied by the job that composes the XCFramework.
This change stores the header folder as an artifact in the build job and retrieves it in the compose job, so that the files are available to the XCFramework
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/52010
Test Plan:
Check the generated artefact in CI
<img width="292" alt="Screenshot 2025-06-13 at 15 32 02" src="https://github.com/user-attachments/assets/437333da-5848-4657-a9b3-e87fc79c69b2" />
Reviewed By: cortinico
Differential Revision: D76599834
Pulled By: cipolleschi
fbshipit-source-id: 44d74b5f8df545a825ecfe3df2e1898effe41261
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51693
This moves React Native to use the Central Portal URLs rather than the legacy OSSRH ones.
See https://github.com/gradle-nexus/publish-plugin for more context.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D75673984
fbshipit-source-id: 1de6746809eed72f232eac0c3fb4d809c2046620
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51991
This diff introduces a new parameter to customize libraryGenerators used in the codegen, since I'm adding a default object, this diff shoulnd't change any behavior
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D76472495
fbshipit-source-id: 50b9095c7c554e368f65e4c0b5539be0cca51a51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51990
In this diff I'm limiting visibility of internal objects of codegen, these objects are being exported but they are unused, let's avoid exporting them
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D76470809
fbshipit-source-id: 0e168558d2d3211ab5a3a3de05e2495d7c1ae4f5
Summary:
FIXED Add index.js.flow to npm package files for Flow support
Currently, the distributed npm package for react-native does not include the index.js.flow file, which causes all exports to be typed as any when using Flow. This commit adds index.js.flow to the "files" array in package.json, ensuring Flow users receive proper type definitions out of the box. This addresses issues where type checking with Flow fails in React Native projects.
## Changelog:
[General][Added] Publish top-level Flow types for `react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/51908
Reviewed By: huntie, necolas
Differential Revision: D76292301
Pulled By: robhogan
fbshipit-source-id: e56360d3f35af30ef160470181349aac1812e7c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51966
This starts off mechanically, but needed a couple changes:
1. Some null handling changes to `TextTransform` internals
2. We type MapBuffer keys as `Int` instead of `Short`, because Kotlin does not allow the implicit widening cast that Java does. I also made these internal
3. Some shifts around casting
4. Mark TextLayoutManager internal, and remove usages of `UnstableReactNativeAPI`
I verified that there were no usages of the Java side of TextLayoutManager throughout `react-native-libraries`, so marking TextLayoutManager internal is unlikely to break 3p libraries.
Changelog:
[Android][Breaking] - Make Java Side TextLayoutManager Internal
Reviewed By: javache
Differential Revision: D76444163
fbshipit-source-id: aabb1c498c731598559f0df5c12e0ecdc266339f
Summary:
This diff adds macros around the legacy architecture core.
To compile out the legacy architecture, simply set: -DRCT_FIT_RM_OLD_RUNTIME=1.
* RCTBridge: interface kept around
* RCTRootView: interface kept around
* RCTSurface: interface kept around
* RCTModuleData: interface kept around (used by RCTProfile)
* RCTProfile: Kept around (doesn't work in bridgeless...)
* RCTCxxBridge: interface kept around
* c++ bridge: removed
* legacy components in core: kept around (for now)
## Details
I added comments to each of the #else, and #endif directives. That way, we can more easily codemod this code in the future.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D72582307
fbshipit-source-id: 018d11cc488e97e60040bebf647f24f2437a57ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51977
This will help the Kotlin migration of ReactDelegate.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D76518840
fbshipit-source-id: 8a24c20705aa6b04af693a6229235b11f30e0bc8
Summary:
Static code analysis shows that there are a lot of unresolved KDoc references. Also, there are a lot of functions incorrectly linked in the comments that were using `[.yourFunction]` instead of `[yourFunction]` – this diff addresses many of them.
## Changelog:
[INTERNAL] - Kotlin: fix up several KDoc annotations
Pull Request resolved: https://github.com/facebook/react-native/pull/51961
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: fabriziocucci
Differential Revision: D76481171
Pulled By: Abbondanzo
fbshipit-source-id: dd55e8fc3abfeaefc9c3762632a05fb7baf63530
Summary:
I've done a pass and cleaned up the changelog for 0.80 ahead of the release
Changelog:
[Internal] -
bypass-github-export-checks
Reviewed By: fabriziocucci, cipolleschi
Differential Revision: D76511997
fbshipit-source-id: 3872f9adbf16767c466e4dbb72d70fdaf2defde3
Summary:
This parameter can be null and is causing failures on some tests. This fixes
it.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: lenaic
Differential Revision: D76505211
fbshipit-source-id: a23fca21daf5292bc7375e7d025d1202cc591b86
Nicola Corti
Janic Duplessis
Jorge Cabiedes Acosta
Alan Lee
David Vacca
Riccardo Cipolleschi
Mateo Guzmán
Tim Yung
Samuel Susla
Pieter De Baets
Ramanpreet Nara
Andrew Datsenko
Mathieu Acthernoene
Arushi Kesarwani
Christoph Purrer
Alexander Klotz
generatedunixname89002005287564
Aswin Andro
Nick Gerleman
Oskar Kwaśniewski
Jorge (Hezi) Cohen