Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53619
With this change, we are making Codegen generate a Package.swift file so that we can integrate the `ReactCodegen` and the `ReactAppDependencyProvider` in apps only using SwiftPM
## Changelog
[iOS][Added] - Make codegen generate PAckage.swift file for the codegen targets
Reviewed By: cortinico
Differential Revision: D81769543
fbshipit-source-id: 1f1a1b9f41126e142931d5eda6e75109a69f828c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53618
This change makes sure that we generate the codegen files in the ReactCodegen and ReactAppDependencyProvider folder.
This is necessary as Swift PM needs the source code of packages to be grouped in folders that are children of where the Package.swift is located.
This is not a breaking change, because Cocoapods has been updated accordingly, import/include paths are not changed and the folder layout should not be accessed by anybody directly
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D81769522
fbshipit-source-id: 7c70f96a9aa503c4faaf173b94c8ee0e326094a1
Summary:
Follow-up to https://github.com/facebook/react-native/issues/53503 for a regression
When no React Native module is present this bail condition stops us from generating the artifacts podspec that's needed to complete build.
## Changelog:
[IOS] [FIXED] - Fix regression that skips artifacts code generation
Pull Request resolved: https://github.com/facebook/react-native/pull/53690
Test Plan:
- Create an app **without** any React Native modules, run `pod install`; without this fix the podspec will be missing and the build will fail
- With expo this can be reproduced using `create-expo-app --template blank-typescript@next` on `react-native@0.81.2`
- With the community CLI this can be reproduced using `npx react-native-community/cli@latest init test --skip-install --version 0.81.2` and uninstalling `react-native-safe-area-context`
Reviewed By: javache
Differential Revision: D82103491
Pulled By: cipolleschi
fbshipit-source-id: 3d9619b5a935ca920220824b3963a9a107f926ca
Summary:
We had reports from the Community of the RN CI running on forks and causing high costs and bills for them
This change should make sure that the most impactful jobs only runs on the React Native CI and not on forks.
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/53707
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D82107313
Pulled By: cipolleschi
fbshipit-source-id: ff7f418344975e7bb8306a6356d774c26bea3db1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53660
Changelog: [internal]
(This is internal because these APIs aren't enabled in OSS yet)
Implements `performance.timeOrigin` to allow converting timestamps from `performance.now()` to be based on the Unix epoch.
This implementation isn't fully spec-compliant to align with the current implementation of `performance.now()`, where the base of the clock is system boot time instead of app startup / navigation time.
Reviewed By: huntie
Differential Revision: D82016724
fbshipit-source-id: e3a066721cecf41e2fd963beb94a0a2f1c5d6493
Summary:
This PR adds additional checks to run nightly jobs only on the main repo.
I noticed pretty heavy usage on my fork of React Native:
<img width="951" height="179" alt="Screenshot 2025-09-10 at 11 47 29" src="https://github.com/user-attachments/assets/91cb9e4a-8658-42bd-bbfe-ffba01b0b3b3" />
I also noticed a typo in this file with output instead of outputs
## Changelog:
[INTERNAL] [FIXED] - add conditional checks for facebook/react-native repo for nightly workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/53700
Test Plan: Check if the syntax is correct.
Reviewed By: cortinico
Differential Revision: D82104958
Pulled By: cipolleschi
fbshipit-source-id: fc2e6e0299345ebd115c7a574a5a8161f2b0ca5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53665
Changelog: [ANDROID][FIXED] - Read the Hermes V1 opt-in flag from the apps properties when building from source
Reviewed By: cortinico
Differential Revision: D82018545
fbshipit-source-id: f3c6fdbac190f47b6bf6836105d9e0909d8b86ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53689
## Changelog:
[General] [Fixed] - fix array type parsing in DynamicEventPayload::extractValue
When unwrapping event mapping like `e.nativeEvent.touches[0].locationX` e.g. for Animated.event like below,
```
onTouchMove={Animated.event(
[
{
nativeEvent: {
touches: {
0: {locationX: animatedValue},
},
},
},
],
{useNativeDriver: true},
)}
```
here it'll throw exception `terminating due to uncaught exception of type folly::TypeError: TypeError: expected dynamic type 'object', but had type 'array'` when getting into folly dynamic array, because array index in the event path is string instead of integer
Reviewed By: rozele
Differential Revision: D82050538
fbshipit-source-id: ed25c8917b90190c995d1fcd6d60af207e72e270
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53547
Changelog: [internal]
This creates a new feature flag to enable the modern Web performance APIs in RN by default. It's disabled by default so it shouldn't have any effect at the moment.
Reviewed By: rshest
Differential Revision: D80811430
fbshipit-source-id: 47d5fd12ac8809aa3c5ad37cdd31c0d9e3ed5912
Summary:
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
Fixes a crash in `RCTDeviceInfo.interfaceOrientationDidChange` when `application.delegate.window` is nil. This crash affects multiple modern iOS app architectures where the traditional window property may not be set:
- **SwiftUI apps using `main`** instead of traditional AppDelegate
- **Brownfield React Native integrations** where the host app manages windows
- **Scene-based lifecycle apps** (iOS 13+) using SceneDelegate
- **Custom window management** setups
**The Problem:**
```
*** Terminating app due to uncaught exception 'NSInvalidArgumentException',
reason: '-[MyApp.AppDelegate window]: unrecognized selector sent to instance'
```
This occurs when trying to access `.frame` on a nil window object during orientation changes. Modern iOS development patterns don't always require setting `application.delegate.window`, but React Native's RCTDeviceInfo assumes this property exists.
**The Solution:**
Replace direct `application.delegate.window` access with `RCTKeyWindow()` and add nil-safe fallback:
```objc
// Before (crashes in modern apps)
BOOL isRunningInFullScreen =
CGRectEqualToRect(application.delegate.window.frame, application.delegate.window.screen.bounds);
// After (safe for all app configurations)
UIWindow *delegateWindow = RCTKeyWindow();
BOOL isRunningInFullScreen = delegateWindow ?
CGRectEqualToRect(delegateWindow.frame, delegateWindow.screen.bounds) : YES;
```
This approach:
- Uses `RCTKeyWindow()` pattern already established elsewhere in RCTDeviceInfo
- Provides safe fallback defaulting to fullscreen when window state is unknown
- Maintains existing multitasking detection behavior (Split View, Slide Over)
- Is backward compatible with traditional React Native apps
## 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] - Fix RCTDeviceInfo crash when application.delegate.window is nil in modern iOS app architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/53645
Test Plan:
### Manual Testing
**1. SwiftUI main App Test:**
```bash
# Created SwiftUI app with main lifecycle
# Integrated React Native component
# Result: No crash during orientation changes, fullscreen detection works
✅ PASS: Orientation changes handled safely
✅ PASS: Multitasking detection stable
```
**2. Traditional React Native App:**
```bash
# Tested with standard RN template app
# Verified existing behavior unchanged
✅ PASS: Existing functionality preserved
✅ PASS: No regressions in dimension reporting
```
**3. Brownfield Integration:**
```bash
# Integrated RN in existing iOS app without window property
# Triggered orientation changes and multitasking transitions
✅ PASS: No crashes during orientation events
✅ PASS: Split View and Slide Over work correctly
```
**4. Scene-based Lifecycle App:**
```bash
# Created app using SceneDelegate for window management
# Tested orientation and multitasking scenarios
✅ PASS: Proper handling when SceneDelegate manages windows
✅ PASS: No crashes during app lifecycle transitions
```
### Edge Case Testing
**RCTKeyWindow() Returns Nil:**
- Confirmed defaults to `YES` (fullscreen)
- No crashes when no key window available
- Multitasking detection remains stable
**Multiple Window Scenarios:**
- Tested with iPad multiple windows
- Uses correct key window for measurements
- Proper behavior in complex window hierarchies
**Orientation During Transitions:**
- App backgrounding/foregrounding during orientation
- Multitasking mode changes during rotation
- No crashes or inconsistent states
### Automated Testing
```bash
# All existing tests pass
yarn test
✅ RCTDeviceInfoTests pass
# Code style compliance
yarn lint
✅ Follows React Native Objective-C guidelines
```
### Impact Verification
**Before Fix:**
- Crash in SwiftUI apps using main
- Crash in Scene-based lifecycle apps
- Crash in brownfield integrations
**After Fix:**
- All app architectures work safely
- Multitasking detection preserved
- Backward compatibility maintained
- No performance impact
Rollback Plan:
Reviewed By: javache
Differential Revision: D81931754
Pulled By: cipolleschi
fbshipit-source-id: c3ea1a2922b1d48ca6bc1fc32861b490322fd254
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53484
Refactor to better organise network event reporting features.
- Introduce new `ReactCommon/react/networking` package, containing `NetworkReporter` class (outer-most interface with each platform).
- Move `ReactCommon/performance/timeline` dependency to this level, removing jsinspector→performance dependency.
- Simplifies the remaining `NetworkHandler` in `jsinspector-modern/network` — which now is only focused on CDP network reporting.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D81129562
fbshipit-source-id: 6c36045e872b0fd9510d0fa3e98acb0969e74d72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53617
In the RCTAppDelegate.h file there are a couple of headers that are not used and that can be either removed or moved to the .mm file.
This reduce the coupling between the AppDelegate library and React Core and allow us to reduce the size of the exported headers in the umbrella header.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D81769485
fbshipit-source-id: b811dde0331e8a668618e0c8eb250fd81bf48545
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53641
This extra quote is causing the build on the 0.82-stable to fail. The reason is that the Path for the `.hermesversion` file is composed wrongly so we attempt to build hermes from the `main` branch.
Changelog:
[Internal] [Changed] -
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: j-piasecki, vzaidman
Differential Revision: D81925624
fbshipit-source-id: 700f9d44b6c7efdb845232dad8ca7c2e3136385d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53637
Changelog: [ANDROID][FIXED] - Check for the value of the HERMES_V1_ENABLED flag instead of whether it's defined
Reviewed By: cortinico
Differential Revision: D81920483
fbshipit-source-id: 550ae9fd27f666affe102b1c5c3f51bde7b5923e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53628
Bump the `memfs` dependency used in tests to the latest minor - there have been a considerable number of updates since 4.7 including support for various newer (and some old) Node fs APIs: https://github.com/streamich/memfs/blob/master/CHANGELOG.md
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D81879137
fbshipit-source-id: e75946dac100809cb39c88971fd6ed397dc9f49e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53630
These JavaScript apis were a part of react native's legacy architecture. Let's deprecate them, so that we can eventually remove them in the future.
Changelog: [General][Deprecated] - Deprecate legacy javascript react native apis
Reviewed By: cortinico
Differential Revision: D81795732
fbshipit-source-id: 0a2bd142fa7e08c1f3daaa437ee127a2156e045b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53622
Reverting to avoid lossy conversion on hosts expecting signed int values for color conversion.
Changelog: [Internal]
Reviewed By: rozele, javache
Differential Revision: D81785268
fbshipit-source-id: 4a8d099e378fa55e76a58c2ab0356d88e344de2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53589
## Changelog:
[Android] [Changed] - [c++ animated] Course correct props at SurfaceMountingManager.updateProps()
Sometimes a React update will try to commit to the same view that native animated modified before via direct manipulation, and after the update host view will use the prop value currently in Fabric. In `AnimatedMountingOverrideDelegate` there's logic to course correct at ShadowTree mount, but if this update is from JS thread, it takes some time to reach mounting layer, at the same time UI thread can still be doing more direct animation updates, and once the corrected change gets there it's already stale.
In this diff I added mechanism to keep track of direct manipulation props (or "synchronous mount props" to match the naming of java function `synchronouslyUpdateView...`) and use it to correct what reaches host view. `SurfaceMountingManager.updateProps()` is called by both regular mount and direct manipulation and it's always called on UI thread, so it could be a good candidate to synchronize these 2 scenarios
Reviewed By: sammy-SC
Differential Revision: D81611823
fbshipit-source-id: 638a59bcd94b3d7e8bab68defd472b2b482dc92f
Summary:
## Changelog:
[Internal] -
Noticed that the default value for this one is inconsistent with all the other similar ones, which can cause confusion during setting up the experiment, fixing it.
Note that top level view recycling is still controlled via `enableViewRecycling`, which will also disable all the other ones when false (which it is by default).
bypass-github-export-checks
Reviewed By: lenaic
Differential Revision: D81766029
fbshipit-source-id: df4a260b9bde20d1c85b7786df00fa91298a27b7
Summary:
bypass-github-export-checks
OSS release infrastructure for the (experimental) React Native DevTools standalone shell.
Currently, binaries are built continuously on Meta infra and served from the Meta CDN using fbcdn.net URLs checked into a DotSlash file in the repo, e.g.:
https://github.com/facebook/react-native/blob/15373218ec572c0e43325845b80a849ad5174cc3/packages/debugger-shell/bin/react-native-devtools#L9-L18
For open source releases we want to primarily distribute the binaries as GitHub release assets, while keeping the Meta CDN URLs as a secondary option. This PR makes the necessary changes to the release workflows to support this:
* `workflows/create-release.yml` (modified): As part of the release commit, rewrite the DotSlash file to include the release asset URLs.
* **NOTE:** After this commit, **the new URLs don't work yet**, because they refer to a release that hasn't been published. Despite this, the DotSlash file remains valid and usable (because DotSlash will happily fall back to the Meta CDN URLs, which are still in the file).
* `workflows/create-draft-release.yml` (modified): After creating a draft release, fetch the binaries from the Meta CDN and reupload them to GitHub as release assets. This is based on the contents of the DotSlash file rewritten by `create-release.yml`.
* `workflows/validate-dotslash-artifacts.yml` (new): After the release is published, all URLs referenced by the DotSlash (both Meta CDN URL and GH release asset URLs) should be valid and refer to the same artifacts. This workflow checks that this is the case.
* If this workflow fails on a published release, the release may need to be burned or a hotfix release may be necessary - as the release will stop working correctly once the Meta CDN stops serving the assets.
* This workflow will also be running continuously on `main`. If it fails on a commit in `main`, there might be a connectivity issue between the GHA runner and the Meta CDN, or there might be an issue on the Meta side.
NOTE: These changes to the release pipeline are generic and reusable; if we later add another DotSlash-based tool whose binaries need to be mirrored as GitHub release assets, we just need to add it to the `FIRST_PARTY_DOTSLASH_FILES` array.
## Changelog:
[Internal] Mirror React Native DevTools binaries in GitHub Releases
Pull Request resolved: https://github.com/facebook/react-native/pull/52930
Test Plan:
### Step 0: Unit tests
I've added unit tests for `dotslash-utils`, `curl-utils`, and for the majority of the logic that makes up the new release scripts (`write-dotslash-release-assets-urls`, `upload-release-assets-for-dotslash`, `validate-dotslash-artifacts`).
### Step 1: Test release commit
Created a test branch and draft PR: https://github.com/facebook/react-native/pull/53147.
Locally created a release commit, simulating the create-release GH workflow:
```
node scripts/releases/create-release-commit.js --reactNativeVersion 0.82.0-20250903-0830 --no-dry-run
```
This updated the DotSlash file in the branch: https://github.com/facebook/react-native/pull/53147/commits/2deeb7e70376ee80b99f27bea4825789f22a89a3#diff-205a9ff6005e30be061eaa64b9cb50b15b0e909dd188e0866189e952655a3483
NOTE: I've also ensured that the `create-release-commit` script correctly updates the DotSlash file when running from a branch that already has a release commit - see screenshot:
<img width="1483" height="587" alt="image" src="https://github.com/user-attachments/assets/1ffd859b-e02b-483d-8067-9cc9116829a4" />
### Step 2: Test draft release
Enabled testing the create-draft-release GH workflow in the test branch using these temporary hacks:
* https://github.com/facebook/react-native/pull/53147/commits/81f334eac5147d4dbf5f6d7d627ddfa52cd197be
* https://github.com/facebook/react-native/pull/53147/commits/6d8851657629de7e0b710ed8f5dd7d0f7b9847cc
* https://github.com/facebook/react-native/pull/53147/commits/1428a8da8b9fb29c45fc33d79f311dd1fe273433
Workflow run: https://github.com/facebook/react-native/actions/runs/17426711373/job/49475327346
Draft release: https://github.com/facebook/react-native/releases/tag/untagged-c6a62a58e5baa37936e1
Draft release screenshot for posterity (since we'll likely delete the draft release after landing this):
<img width="1024" height="814" alt="image" src="https://github.com/user-attachments/assets/1900da15-48f6-4274-b29c-0ac2019d92c0" />
### Step 3: Test post-release validation script
For obvious reasons, I've avoided actually publishing the above draft release. But I have run the `validate-dotslash-artifacts` workflow on the *current* branch to ensure that the logic is correct: https://github.com/motiz88/react-native/actions/runs/17426885205/job/49475888486
Running `node scripts/releases/validate-dotslash-artifacts.js` in the release branch (without publishing the release first) fails, as expected:
<img width="1105" height="748" alt="image" src="https://github.com/user-attachments/assets/ed23a2e2-7a31-42eb-a324-f1d50eafe2fb" />
## Next steps
This PR is all the infra needed ahead of the 0.82 ~~branch cut~~ infra freeze to support the React Native DevTools standalone shell, at least on the GitHub side. ~~Some minor infra work remains on the Meta side, plus some product/logic changes to the React Native DevTools standalone shell that I'm intending to finish in time for 0.82 (for an experimental rollout).~~ EDIT: All the planned work has landed; the feature is code-complete on `main` as well as in `0.82-stable` (apart from this infra change).
As a one-off, once we've actually published 0.82.0-rc.1, we'll want to have a human look at the published artifacts and CI workflow logs to ensure everything is in order. (I'll make sure to communicate this to the 0.82 release crew.) Afterwards, the automation added in this PR should be sufficient.
Reviewed By: huntie
Differential Revision: D81578704
Pulled By: motiz88
fbshipit-source-id: 6a4a48c3713221a89dd5fc88851674c1ddc6bb10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53558
Changelog: [Internal]
Got confused regarding why "reconnect" does not actually trigger a reconnect. It turns out, it only triggers a reconnect if the URL has changed.
Reviewed By: cipolleschi, huntie
Differential Revision: D80629308
fbshipit-source-id: 098ef5e91f3748deb9bc707b79bc0395d2442ca4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53600
# Changelog:
[Internal] -
Adds the corresponding feature flag, similarly as it's done for other component types.
The flag is used in the next diff.
Reviewed By: mdvacca
Differential Revision: D81681404
fbshipit-source-id: f9f155379034695f5df6cc4f0d3787ff4c69df7f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53578
Changelog: [Internal]
Adds a new preprocessor directive which should be set when the new Hermes is being used. This directive will disable the legacy debugger which isn't supported by it.
Reviewed By: cipolleschi, cortinico
Differential Revision: D81035112
fbshipit-source-id: b30ae348b3419ec2d064dfe7f91c9d664a66f5cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53410
Changelog: [Internal]
Adding babel-istanbul-plugin to instrument bundle code with coverage reporting.
Metro will transform source code only when coverage flag is set up globally in jest.
Coverage map is then provided by runner as part of test result.
Reviewed By: sammy-SC
Differential Revision: D80716433
fbshipit-source-id: 3831f227f8793f874f0d2366759bb6916e747c72