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
Summary:
This is to enable consuming RCTImage pod in mixed ObjC/Swift codebase. W/o this option set I get following error when building the library:
```
Installing RNScreens 4.11.1
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `RNScreens` depends upon `React-RCTImage`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
I've noticed that there is also a precedent in the form of https://github.com/facebook/react-native/commit/c8fcac2765e0f79f0e7bb3a422a65698aec62536, which handled very simlar case but for `React-jsc` pod.
## 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
-->
[IOS] [FIXED] - Allow for consuming RCTImage in Swift codebase by enabling "Defines Module" option
Pull Request resolved: https://github.com/facebook/react-native/pull/51974
Test Plan: RNTester should build & run correctly
Reviewed By: cortinico
Differential Revision: D76505478
Pulled By: cipolleschi
fbshipit-source-id: bcce93ffc7e1c917da7f07db83a710575c659f45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51965
Changes the error handling in `cli.js` scripts for `rn-tester` and `helloworld` so that the original error stack traces are preserved.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D76458284
fbshipit-source-id: 491b2bacc4becb8676a2ed4f1181192632bd808f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51962
Changelog: [Internal] - Migrate debug feature flag to be accessed in both native and JS
Reviewed By: yungsters, mdvacca
Differential Revision: D76381273
fbshipit-source-id: d4071abeb9769821e236c444f89044165cf83d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51944
Ahead of more refactoring, this cleans up a couple feature flags, already on by default, the newest of which added on 5/1, since these should all be validated by significant production usage at this point, so it is unlikely we would want to turn off.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D76412970
fbshipit-source-id: a2612583c060ed3f6fc559864e481d5b5a33fef2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51939
ReactRootView already reliably assigns itself a fresh root tag from its constructor. Assuming this `FabricUIManager.startSurface` method is called with a valid `ReactRoot` instance, we can just re-use the existing tag without minting a new one. This makes some native initialization that depends on root tag assumptions easier to setup.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D76370069
fbshipit-source-id: ad9bb91eee374c911f65ebcdd395716c77881e96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51958
There is a copy and paste mistake, from dependencies to core, when uploading artefacts to maven.
This change fixes it.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76435336
fbshipit-source-id: a829b90ba3d4cbfc5528fc9f21dcee7be6a358ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51893
This diff adds `--validate` flag that runs snapshot validation to determine if the `ReactNativeApi.d.ts` rollup has been changed (if JS public API has been touched). There was also an issue with `sortProperties` that reordered some properties (ex. in ImagePropsBase) after removing one of them (ex. accessible) which had negative impact on the displayed result.
### Motivation
Compare previous snapshot with the one built on the current revision to determine the impact of made changes on the public API surface. Display differences in human readable format using `diff` method from the `jest-diff` library.
For now `--validate` flag is not useful on its own. It should be used with `--withSnapshot` flag (which will be removed shortly and generating snapshot will be a default mechanism).
Changelog:
[General][Added] - Add `--validate` flag to `build-types` script for JS API snapshot validation.
Reviewed By: huntie
Differential Revision: D76135158
fbshipit-source-id: 53f5b142c66e3e3931961f741c3f2fab8ccdc228
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51957
We need to rename the artifacts correctly for Sonatype to pick them up.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76428060
fbshipit-source-id: 83f1da75fbbdd4317ec791a6e782bbaa5c05fa5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51956
While working on landing the prebuild for React Native core in CI, I forgot to add a strong dependency between the build_npm_package job and the prebuild_react_native_core job in the workflow.
It was still technically working, because there are other jobs that are slower than building react_native_core that will delay built_npm_package for enough time, but this fix will make it more robust.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76423766
fbshipit-source-id: 76d91901d63e95add62f26bbff4de0278e8609e3