Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55136
Stacking another diff on top of hermes release. Let's see if there's still any CI failures.
` js1 flow-runner codemod flow/transformUtilityType --format-files=false --legacy-type='$Values' xplat/js`
drop-conflicts
Reviewed By: gkz
Differential Revision: D90549059
fbshipit-source-id: e07faa80b5ed0a675a2bc9bcc45d4084aaae9eda
Summary:
This change makes Hermes V1 the default engine for React Native for both platforms. This change needs to land before the branch cut of react native 0.84
bypass-github-export-checks
## Changelog:
[iOS][Changed] - Make Hermes V1 the default engine for iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/54989
Test Plan:
1. Run `bundle exec pod install` and verified that Hermes V1 is used when building from source
<img height="480" alt="Simulator Screenshot - iPhone 17 Pro - 2025-12-29 at 11 28 44" src="https://github.com/user-attachments/assets/0889f16c-f2ee-4a0e-9a4d-529dd82c8283" />
2. Run `prebuild-ios -s` and verified that the scripts downloads the Hermes V1 tarball
<img width="831" height="324" alt="Screenshot 2025-12-29 at 10 37 53" src="https://github.com/user-attachments/assets/9a60565e-1e13-4967-a4a4-dd079e6b040f" />
3. GHA and nightlies
Reviewed By: vzaidman, cortinico, huntie
Differential Revision: D89881943
Pulled By: cipolleschi
fbshipit-source-id: 958b6d31bd4230ba4a5c7fee2bffc19e03dcbc89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/55034
Delete the `yarn print-packages` script.
- `yarn workspaces info` already exists.
- Since implementing lockstep versioning, all pkg versions are at a single version string (or `0.0.0` for private).
- This script also offers npm lookups for older versions — same assertion goes.
- Since adding the `private/` directory, the public/private package delineation is increasingly clear on its own (remaining exception: RNTester).
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D90106362
fbshipit-source-id: bbba97984a80473f92b331cb68d01b5ad00a2b55
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54901
At present, we're only using a rough heuristic for whether a code change to `ReactNativeApi.d.ts` is a breaking change. Introduce `POTENTIALLY_BREAKING` result level and update Danger warnings box.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D89287801
fbshipit-source-id: aced7911ecde37a1ad2c355d56ef0f0edde88fd4
Summary:
### Motivation
Updates the shared JavaScript build setup to use the modern `publishConfig` convention.
This:
- Simplifies the build script.
- Makes the production values for `"exports"` more understandable in place (especially by separating from exports conditions).
- Prevents us from creating a dirty file state when running `yarn build`.
### Changes
- Add `publishConfig` to each `package.json` listing production `"exports"` targets.
- Add `scripts/build/prepack.js` script to action `publishConfig` (now on `npm pack`, `npm publish` exclusively).
- Remove `"exports"` rewriting (and un-rewriting safeguards) from build script.
**Note on `"prepack"`**
Slightly unfortunately, `publishConfig` doesn't work consistently between package managers currently, including npm — so this does not work implicitly (but may in future).
We're instead following `publishConfig` as a convention, and explicitly implementing a full copy (theoretically forking us towards pnpm and Yarn v4's approach).
However, I believe this is:
- Worthwhile, for the motivations above — and in particular being able to understand the final shape of `"exports"` (independent from the dimension of conditional exports, which may come into play later).
- Completely inspectable/maintainable as an explicit implementation (`scripts/build/prepack.js`).
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/54857
Test Plan:
### CI
✅ GitHub Actions
### End-to-end release test script
(Note: Rebased on `0.83-stable` when tested)
```
yarn test-release-local -t "RNTestProject" -p "iOS" -c $GITHUB_TOKEN
```
{F1984106139}
✅ Test script runs `npm publish` on packages to a local proxy.
{F1984106146}
✅ Installed packages have `publishConfig` `"exports"` values applied
NOTE: ⬆️ This is **exactly** the same output as before.
{F1984106148}
✅ `/tmp/RNTestProject` runs using built + proxy-published + proxy-installed packages
Reviewed By: cipolleschi
Differential Revision: D88963450
Pulled By: huntie
fbshipit-source-id: f328252cf93a1f1039b79d7f369d1e6e7e5b4b52
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54822
Updates hash generation in `versionExportedApis.js` to track changes to `declare const` type declarations like `AccessibilityInfo_default`.
Previously, changes to APIs (e.g., `AccessibilityInfo`) would not always update their hashes in `ReactNativeApi.d.ts`, causing the breaking change detection to miss actual API changes.
Three issues prevented proper hash tracking:
1. **`VariableDeclaration` types weren't tracked** - `declare const X: {...}` was not in the list of tracked declaration types
2. **Duplicate declarations caused overwrites** - `declare type X = typeof X` would overwrite `declare const X: typeof X_default` in the declarations map, losing the dependency on `X_default`
3. **`typeof X` queries weren't extracting dependencies** - references via `typeof` weren't being added to the dependency graph
## Fix
- Add `t.isVariableDeclaration(node)` to tracked types with proper name extraction
- Prevent overwriting existing declarations (first declaration wins)
- Handle `TSTypeQuery` nodes to extract `typeof X` dependencies
### Note on Hash Changes
This PR causes many hashes to change, even for types that haven't been modified. This is expected because the hash computation now includes `declare const` dependencies that were previously ignored.
**Before:** `AccessibilityInfo` hash only included `declare type AccessibilityInfo = typeof AccessibilityInfo` (self-reference)
**After:** Hash now includes `declare const AccessibilityInfo: typeof AccessibilityInfo_default` + the full `AccessibilityInfo_default` type
## Changelog:
[GENERAL] [FIXED] - hash generation includes `declare const` types in API snapshot
Reviewed By: huntie
Differential Revision: D88653322
fbshipit-source-id: abdf9c5e11bf8ff9e6e2f17a743a2d5aa213ae1c
Summary:
This replaces `glob@^7.0.0` with `tinyglobby@^0.2.15`. `glob@7` has been deprecated for a while and some versions after had security notices released for them. The plan is to backport this PR to `0.81.x` and onwards.
> [!NOTE]
> This is a stopgap solution until `fs.glob` becomes generally available with the EOL of Node v20
Succeeds:
- https://github.com/facebook/react-native/issues/54669
- https://github.com/facebook/react-native/issues/48875
## Changelog:
[GENERAL] [SECURITY] - Replace `glob@^7.0.0` with `tinyglobby@^0.2.15`
Pull Request resolved: https://github.com/facebook/react-native/pull/54737
Test Plan:
- Ran all modified commands manually and `pod install in `rn-tester`
- NOTE: `ios-prebuild`-related scripts haven't been run manually yet
Reviewed By: robhogan
Differential Revision: D88069145
Pulled By: huntie
fbshipit-source-id: 0c455342a4c6d1d6605fd09fe47b418e5d751491
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54704
This class is coming from Legacy Architecture and is no longer used so can be cleaned up.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D87925037
fbshipit-source-id: 30faffef0da2b7055a6d381b41dc72bead2dd8de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54684
This diff removes the `RCTTurboModuleSyncVoidMethodsEnabled` feature flag and all related code that allowed TurboModule void methods to execute synchronously.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D87865883
fbshipit-source-id: fa64e8105e8329a0b20bb1718dbc01b17464cd06
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54521
Following D86869721, this removes the unused `name`, `version`, and `license` fields from the project level `package.json` (previously named `react-native/monorepo`).
**Motivation**
- **Simplicity**: Our root package.json is a Yarn project manifest, not a package, with the `version` field serving no functional purpose. `react-native/monorepo` was never published to npm, and so `name`, `version`, and `license` were never read.
- **Correctness**: Since D86869721 and our recent work to formalise monorepo dependencies in `private/`, the workspace root no longer needs to be referenced by any part of our containing fbsource codebase — and this is a conceptual footgun (Yarn-installing a package that is itself a workspace). `react-native/monorepo` no longer needs to be named, addressable, or installable.
Or, phrased another way:
- Delete `name` — never try to reference this as an npm package!
- Delete `version` — never think about versioning this file!
- Delete `license` — unread, duplicate of `LICENSE.md`.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D86869720
fbshipit-source-id: dcc5fd33bb8c2354d94306e3fb37bbae3f4af43e
Summary:
This is a port back in main of the commit a0e40ec09f we landed in the 0.83-stable branch to fix the release process of React Native.
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/54495
Test Plan: GHA + tested while doing the release
Reviewed By: huntie
Differential Revision: D86766812
Pulled By: cipolleschi
fbshipit-source-id: 0e5664b3ceed32fd05fdfe3fca1bffead9d3eae1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54479
Fixes failing CI jobs on `0.83-stable`, e.g. https://github.com/facebook/react-native/actions/runs/19234912061/job/54982161510.
**Changes**
- Simplify main package `package.json` file read with existing `getWorkspaceRoot` util.
- Fix test by mocking `getWorkspaceRoot` (previously: read the real filesystem and caused test breakage outside `main`).
- Add additional `RC0 → RC1` test case.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D86674348
fbshipit-source-id: 0b8feb4cbf7b1ac7cf4cc560f066a0a10aec1b5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54451
Restores behaviour pre-D76358273. `rn-tester` is a special case package that we do want to version, even though it's marked as `private: true`.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D86534510
fbshipit-source-id: 5557e22361bba82a6acaa5eab911002bb9894ae4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54404
Changelog: [Internal]
Updates the `publish-npm` script, so that it doesn't try to use the latest (nightly) releases of Hermes when invoked on a stable branch before a version is updated from 1000.0.0.
This is the same change as the one used for 0.83 release: https://github.com/facebook/react-native/pull/54402.
Reviewed By: cipolleschi
Differential Revision: D86201041
fbshipit-source-id: 6e6fc2981853ca1218913e224c97fadea48a72f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54385
Changelog: [Internal]
`test-release-local` shouldn't be changing the hermes version stored in `version.properties` as this script should be called on a cut branch with hermes already bumped.
Reviewed By: cipolleschi
Differential Revision: D86105703
fbshipit-source-id: 5a1edd9f7a6cd756521749c2b0023ea683dadf82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53837
Changelog: [Internal]
Replaces usage of Hermes built inside the React Native repository with the release published from the Hermes repo.
Reviewed By: cipolleschi
Differential Revision: D82721725
fbshipit-source-id: 357d5e2b914675ec6e60f810c382a945aa461732
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53985
Changelog: [Internal]
Updates the release scripts to set the Hermes version independently from React Native.
Reviewed By: cipolleschi
Differential Revision: D82438054
fbshipit-source-id: 154c19d1d0d16fd5879ad663428d803ceadc5a1f
Summary:
In Flow 0.284, we will have a stricter version of `Array<T>.includes`. Instead of accepting `mixed`, we will only accept `T` to help catch logical errors. We did the same for `Array.indexOf` and `Array.lastIndexOf` as well.
This diff pre-suppresses newly discovered errors in part of the codebase.
Changelog: [Internal]
Reviewed By: marcoww6
Differential Revision: D82784398
fbshipit-source-id: 6cb11809844f964e0604d33b9f7a3989074cd1cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53817
What is currently happening, is that the various commits on the release branches like `0.82-stable` are resetting the version of native artifacts to `1000.0.0-<SHA>`.
The reason is that during the `test-all` workflow, we pass the `dry-run` as release type.
That's to prevent the various tools from calling `npm publish` and so on.
The problem is that on the releases branches, the version was already set at branch cut time.
Therefore, we see the version 1000.0.0 reappearing during Android E2E test in the emulator. Similary this is also affecting iOS prebuilds so I'm attempting to fix it here.
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D82553599
fbshipit-source-id: 31a52e7df036e700663b3d3dd677973a7a210a30
Summary:
The `--otp` flag is completely unused now, therefore it can be removed.
We don't pass the `NPM_CONFIG_OTP` env variable either as this was done back in the days of CircleCI so I'm cleaning this up.
## Changelog:
[INTERNAL] - Remove unused --otp property from release infrastructure
Pull Request resolved: https://github.com/facebook/react-native/pull/53779
Test Plan: CI
Reviewed By: lunaleaps
Differential Revision: D82453539
Pulled By: cortinico
fbshipit-source-id: 84a6b82a037c754165c21e17976dc534d9a7ba4c
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/53480
Changelog: [Internal]
Improves the way `--version` and the User-Agent header work in `debugger-shell`.
* The same app name and version string format will be used across the `dev` and `prebuilt` flavours. Previously, `dev` would report itself as being `Electron v37.2.6` while `prebuilt` would report `react-native/debugger-shell v0.82.0-main`.
* `prebuilt` now also reports the original Meta-internal commit hash as a suffix `-rFBS..........` added to the semver string taken from `package.json`, while `dev` will have a `-dev` suffix in the same place.
* We do **not** modify the version in `package.json` during the build, nor do we pass the commit hash to `electron/packager`, because this would impose inconvenient platform-specific restrictions on the version string's format.
Reviewed By: huntie
Differential Revision: D81120181
fbshipit-source-id: e730dd35da78dfbb8de326f9a3ab76b747fdb0b3
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 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
Marco Wang