github.com-facebook-react-native
all · 63 devs · built 2026-08-09
Repository snapshot
Monthly reports
No monthly reports available yet.
Performance over time
ETV stacked by Growth, Maintenance and Fixes — 90-day moving average, normalized to ETV / month.
Average performance per developer
ETV per active developer per month — 30-day moving average.
Active developers over time
Unique developers committing each day — 90-day moving average.
Knowledge concentration
How dependent is this repo on a small number of contributors? Higher top-1 share = higher key-person risk.
Rubén Norte owns 8.9 % of commits.
Top contributors
Most impactful commits
Top 20 by ETV in the all-time window.
- 11.4ETVfeat(iOS) swiftpm support in iOS (#57332) Summary: ⚠️ This is a stacked PR — review/merge the base PRs first Builds on, and should land after (bottom-up): 1. https://github.com/react/react-native/issues/57285 — Remove the Clang VFS overlay / modularize React headers (base of the stack). <React/…> via the framework module map; lowercase namespaces (react/, yoga/, jsi/, …) via the ReactNativeHeaders module map. 2. https://github.com/react/react-native/issues/57305 — Prebuilt artifact resources + ReactNativeHeaders.xcframework. Ships the prebuilt core artifacts (incl. ReactNativeHeaders in the tarball + embedded React.framework resources) and the CocoaPods React-Core-prebuilt facades. 3. https://github.com/react/react-native/issues/57440 — Self-serving prebuilt ReactNativeDependencies + dependency-only facades. The deps pod becomes the single header authority for the third-party namespaces (RCT-Folly/glog/boost/…); community `s.dependency "RCT-Folly"` resolves to local facades instead of trunk source pods. 4. https://github.com/react/react-native/issues/57442 — ReactNativeDependenciesHeaders sidecar + pure-RN ReactNativeHeaders (immediate base). The deps prebuild emits a headers-only LIBRARY-type sidecar (the binary deps xcframework is framework-type — invisible to SwiftPM binaryTargets), ReactNativeHeaders drops the third-party namespaces, and both headers artifacts publish standalone to Maven. The whole stack is rebased onto current main (2026-07-06). This PR consumes the final **five-artifact set**: React, ReactNativeHeaders (pure-RN), ReactNativeDependencies, ReactNativeDependenciesHeaders, hermes-engine. Adds npx react-native spm and the package-generation tooling that turns an app into a SwiftPM-integrated RN app using the base stack's prebuilt XCFrameworks. CocoaPods stays supported — additive, opt-in, no Ruby toolchain. Integration is injected into the existing .xcodeproj in place (nothing generated/renamed/replaced), recorded in .spm-injected.json so it reverses exactly. ### What this PR adds - The spm CLI (add/update/deinit/scaffold + hidden sync/codegen/download), zero-arg auto-resolution, --deintegrate for CocoaPods→SwiftPM. - SwiftPM package generation (scripts/spm/): autolinking→Package.swift, Codegen→React-GeneratedCode, core XCFramework binary targets, artifact download/cache, surgical pbxproj inject/remove. - ReactNativeDependenciesHeaders wired as the 5th binaryTarget: the headers-only companions (ReactNativeHeaders from the core tarball, the deps sidecar from the deps tarball) are staged automatically out of their parent tarballs — no --headers-tarball priming; REQUIRED_ARTIFACTS covers all five. - Community-library scaffolding from podspecs (incl. root-level-source podspecs via generated include/<SwiftName>/ shims, sibling wiring for transitive spm.dependencies, self-ingestion guards). - In-place Xcode integration (XCLocalSwiftPackageReference + Sync build phase + scheme pre-action + auto-sync; ${PODS_ROOT}-anchored REACT_NATIVE_PATH replaced on --deintegrate with exact deinit rollback). - rn-tester + helloworld SwiftPM consumption + test library; npm-packaging hygiene; a small RNCoreFacades.podspec_dir fix. ## Documentation - **Tool docs** (usage, quick start, architecture): [`scripts/spm/__doc__/spm-scripts.md`](https://github.com/react/react-native/blob/chrfalch/swift-package-manager/packages/react-native/scripts/spm/__doc__/spm-scripts.md) - **Header-paths contract** (how the five artifacts serve headers): [`scripts/spm/__doc__/spm-header-paths-contract.md`](https://github.com/react/react-native/blob/chrfalch/swift-package-manager/packages/react-native/scripts/spm/__doc__/spm-header-paths-contract.md) - **RFC** (updated): [react-native-community/discussions-and-proposals#994](https://github.com/react-native-community/discussions-and-proposals/pull/994) ## Changelog: [IOS] [ADDED] - `npx react-native spm` command + SwiftPM package-generation tooling (opt-in; CocoaPods stays supported) Pull Request resolved: https://github.com/react/react-native/pull/57332 Test Plan: 350 scripts/spm unit tests (incl. byte-identical add→deinit round-trip); manual E2E against the five-artifact set: fresh app via `cli init`→`spm add --deintegrate`→build (artifact resources verified in the app), rn-tester in-place migration (RNTesterPods.xcodeproj, test libraries + spmModules), helloworld in-place migration — all BUILD SUCCEEDED. Verified `npx react-native spm <cmd>` from the command line in each journey. ## Scope & limitations iOS, prebuilt-only (no build-from-source yet); full spm.xcframework/spm.source library metadata not yet (app-local spm.modules + scaffolding are); Expo not yet. ## Follow-ups Remote-mode ReactNative Package.swift must vend the ReactNativeDependenciesHeaders product (spm-distribution repo); library self-containment for repo-portable manifests; build-from-source. Reviewed By: mdvacca Differential Revision: D111449548 Pulled By: cipolleschi fbshipit-source-id: 87a873bf5c8be2d60f7893611e16924bfa730a46Christian Falch · 47fad096 · 2026-07-15
- 4.1ETVMove c++ native animated code to github (#51509) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/51509 ## Changelog: [Internal] [Added] - Move c++ native animated code to github ⚠️ Note that this is not buildable in OSS yet ⚠️ Reviewed By: sammy-SC, rshest Differential Revision: D75169430 fbshipit-source-id: 499ce209f815474f12007c3c74f81fe0c9ad3f86Zeya Peng · cb02744f · 2025-05-22
- 3.0ETVGenerate nested scroll view (#55239) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/55239 This diff adds the ability to experiment with using `NestedScrollView` instead of `ScrollView` as the parent class for `ReactScrollView` on Android. Since Java doesn't support multiple inheritance or conditional parent class selection, this is implemented using code generation: - A Node script (`generate-nested-scroll-view.js`) generates `ReactNestedScrollView.java` and `ReactNestedScrollViewManager.kt` from their respective source files - The generated files are identical to the originals except they extend `NestedScrollView` instead of `ScrollView` - A Buck genrule verifies the generated files stay in sync with source files at build time - The `useNestedScrollViewAndroid` feature flag controls which implementation is used at runtime This approach allows us to safely A/B test the NestedScrollView implementation without requiring JS changes, since both managers register with the same `REACT_CLASS` name (`"RCTScrollView"`). Changelog: [Internal] Reviewed By: alanleedev, javache Differential Revision: D90902079 fbshipit-source-id: 96ccd25b9a217b8e0cd4e3b542b9dda67047cde3Peter Abbondanzo · 5e93036a · 2026-01-21
- 2.0ETVDelete fixTextClippingAndroid15useBoundsForWidth() (#56282) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/56282 Fixes https://github.com/facebook/react-native/issues/56185 Fixes https://github.com/facebook/react-native/issues/56186 Fixes https://github.com/facebook/react-native/issues/56187 Delete the `fixTextClippingAndroid15useBoundsForWidth()` feature flag and all code gated behind it. This flag was never shipped, and the new code path has been implicated in several bugs. The change removes: - The feature flag definition and all generated plumbing (C++, JNI, Kotlin, JS) - The visual-bounds-based width measurement path in `TextLayoutManager.kt` - The `setUseBoundsForWidth(true)` call in `buildLayout()` - The MobileConfig parameter (`react_fabric.fix_text_clipping_android_15_use_bounds_for_width`) - The Facebook Android and OSS Experimental overrides The old advance-based width logic is retained as the sole code path. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D98427218 fbshipit-source-id: 7c322353d9c0a0548386a486ecd4280b73a66872Nick Gerleman · 5964a197 · 2026-03-31
- 1.9ETVrefactor(ios): remove clang VFS overlay, resolve headers via new ReactNativeHeaders framework (#57285) Summary: The prebuilt `React.xcframework` previously relied on a Clang VFS overlay (`React-VFS.yaml`) to make headers importable, because the headers were laid out in CocoaPods-style namespaced folders rather than standard framework conventions. The overlay had to be generated at build time, re-resolved at pod-install time per slice, and injected as `-ivfsoverlay` flags into every Obj-C, C++, and Swift compile (including aggregate and third-party pod targets). This is fragile, hard to reason about, and incompatible with SwiftPM consumption. This PR removes the VFS overlay entirely and resolves headers through standard framework/header-search-path mechanics instead. **Headers are now emitted into the artifact according to an explicit, executable spec:** - **`React.xcframework`** — each slice's `React.framework` carries every `<React/...>` header plus a framework module map, so `#import <React/...>` and `import React` resolve through `FRAMEWORK_SEARCH_PATHS` automatically. - **`ReactNativeHeaders.xcframework`** (new, headers-only) — carries every other namespace (`<react/...>`, `<yoga/...>`, `folly`, `glog`, …), shipped alongside in the prebuilt tarball and exposed via a single header search path. - This makes `ReactNativeDependencies` binary-only. No clang VFS overlay, no per-target `-ivfsoverlay` flags. The layout is driven by a single source of truth (`headers-spec.js`, rules R1–R11) that both the prebuild compose step and downstream SwiftPM tooling derive from, so the shipped header set cannot drift from the spec. Source headers are byte-identical to the repo — the only consumer-facing change needed is bare-form angle includes (`#import <RCTAppDelegate.h>` → `#import <React/RCTAppDelegate.h>`). **Consumer surfaces the flattened layout initially dropped are restored** (validated against Expo and community Fabric modules): - Private headers (`RCTBridge+Private.h` + the Fabric `RCTComponentView*` family) are exposed in the `React` module map — modular where safe, `textual` where they reach C++ — so frameworks like Expo compile unchanged, incl. Swift access to `RCTBridge.moduleRegistry`. - `React_RCTAppDelegate-umbrella.h` is re-emitted (derived from the live header set) for consumers probing it via `__has_include`. - Sources shipping under multiple include spellings (`React/X.h` + legacy `CoreModules/…`, `RCTImage/…`, bare aliases — 116 today) keep content at ONE module-owned spelling; other spellings become generated redirect shims, so `-fmodules` consumers cannot hit duplicate declarations. - The `React-RCTFabric` facade re-vends `RCTFabricComponentsPlugins.h` at `header_dir "React"`, keeping community Fabric modules' quoted `#import "RCTFabricComponentsPlugins.h"` working as with source pods. **The layout is verified at generator time** (`headers-verify.js`, runs in the prebuild compose CI job): unresolvable includes ratchet against a committed baseline, composed module maps/umbrellas must byte-match the spec render, and consumer-shaped compile smokes must pass (the `React` module, every namespace module, an Expo-shaped ObjC++ fixture, and a Swift `moduleRegistry` fixture). Fail-closed guards cover header collisions, allowlist drift, and missing OR undeclared third-party deps namespaces (the latter surfaced `SocketRocket`, which is deliberately NOT relocated — the real pod vends it, and textual copies collide under `use_frameworks`; the gate asserts its absence). **Key changes** - **New**: `headers-spec.js` (the executable layout contract, R1–R11), `headers-compose.js` (emitter for both xcframeworks), `headers-inventory.js` (podspec-driven header classifier feeding the spec + a diagnostic manifest), `headers-verify.js` (generator-time gate + CI step), `__docs__/headers-rules.md` (rules + rationale). - **Removed**: `vfs.js`, VFS types in `types.js`, and the VFS processing/flag-injection paths in `rncore.rb` and `xcframework.js`. - **Updated**: `React-Core-prebuilt.podspec` (vends both xcframeworks, flattens `ReactNativeHeaders` headers into `Headers/` via `prepare_command`, fails closed on incomplete tarballs), `rncore.rb` / `react_native_pods.rb` (header search path instead of overlay flags), `prebuild-ios-core.yml` (core tarball ships both xcframeworks; compose job verifies the composed headers), README (VFS docs replaced with the new model). - Added facades to the Podspecs that shouldn't be in use when running using precompiled frameworks to satisfy dependencies as empty pod-specs (with the single `RCTFabricComponentsPlugins.h` re-vend exception noted above). ## Changelog: [IOS] [CHANGED] - Remove the Clang VFS overlay from prebuilt React Native Core; resolve headers via React.xcframework + a new headers-only ReactNativeHeaders.xcframework Pull Request resolved: https://github.com/react/react-native/pull/57285 Test Plan: - [x] rn-tester builds against the prebuilt `React-Core-prebuilt` pod (Debug + Release) with no `-ivfsoverlay` flags present in the generated xcconfigs. - [x] rn-tester builds against React native source code (without any prebuilt artifacts) - [x] `#import <React/...>`, `import React;`, and the relocated namespaces (`<react/...>`, `<yoga/...>`, `folly`/`glog`) all resolve. - [x] Prebuilt tarball contains both `React.xcframework` and `ReactNativeHeaders.xcframework`; pod install flattens headers into `React-Core-prebuilt/Headers`. - [x] Switch RN-tester between Debug/Release and verify that both `React.xcframework` and `ReactNativeHeaders.xcframework` are changed between debug and release correctly. - [x] `headers-verify.js` gate green on Debug and Release composes (`-Werror=non-modular-include-in-framework-module` never trips in consumer builds). - [x] `private/helloworld` builds against the prebuilt core (CocoaPods path). - [x] Expo SDK compiles against the prebuilt artifacts (private headers, `React_RCTAppDelegate` umbrella probe, Fabric quoted imports). Reviewed By: fabriziocucci Differential Revision: D111448598 Pulled By: cipolleschi fbshipit-source-id: 72bc2f37765ad425722161a038e410ba976858a5Christian Falch · 376bd0e4 · 2026-07-15
- 1.9ETVDowngrade offscreen Fabric image requests to prefetch (#56976) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/56976 changelog: [internal] Use Fabric layout data to classify image shadow nodes as visible or offscreen on Apple platforms. Offscreen image requests now use `ImageRequestPriority::Prefetch`, which is bridged to the existing `RCTImageLoaderPriorityPrefetch` API, while visible images stay at `Immediate`. The new React Native feature flag defaults to `false` until app-specific gating wires it up. Reviewed By: javache Differential Revision: D106074485 fbshipit-source-id: 80ece75cf0d639be1fdbfdd5f19b838b7b64aba6Samuel Susla · 5fbcc6bf · 2026-05-27
- 1.8ETVFix jagged edge rendering on API 28 (#54525) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/54525 Older versions of Android's clipPath APIs do not properly support antialiasing and BackgroundStyleApplicator relies on this API to clip to border radii that are smaller than provided images or views. As a result, this often leaves jagged edges on the outer edges of these images. Android even calls this out in their documentation under the "Canvas.clipPath" section of https://developer.android.com/topic/performance/vitals/render#common-jank. This change introduces a new API in BackgroundStyleApplicator called `clipToPaddingBoxWithAntiAliasing` which takes an additional argument over the existing `clipToPaddingBox`: a draw call. If non-null and the Android API is 28 or lower, a new drawPath operation is used to mark the pixels outside of the drawn contents as transparent. Changelog: [Android][Fixed] - Fixed antialiasing issues from border radius usage in API <= 28 Reviewed By: haixia-meta, lenaic Differential Revision: D86263195 fbshipit-source-id: 5dba744da08a3c9297f921baf7d4f1a354404f74Peter Abbondanzo · e08abbcb · 2025-11-14
- 1.5ETVAdd Fantom integration tests for core public APIs (#57466) Summary: Pull Request resolved: https://github.com/react/react-native/pull/57466 Adds Fantom `-itest.js` coverage for maintained, public React Native APIs that were previously untested or thinly tested, driving both the JavaScript logic and the underlying cross-platform C++ through the public `react-native` package surface. To make JavaScript-driven animations deterministic under the test runner, this also introduces a small timing indirection in `Animated`: - New module `Animated/AnimationTimingUtils.js` exports `getCurrentAnimationTime` (returns `Date.now()` by default) and `setAnimationTimeProvider` (overrides the time source; pass `null` to restore the default). - `TimingAnimation`, `SpringAnimation` and `DecayAnimation` now read the current time from `getCurrentAnimationTime()` instead of calling `Date.now()` directly. The default behavior is unchanged. With this, a test can override the provider with a clock that advances one frame per read, which drives the JS-driver animation at the same cadence as the native frame clock. The spring and decay tests use this to verify the actual animation curve (overshoot for an underdamped spring, exponential deceleration for decay), not just the final value, and to run a single unified code path for both the JS and native drivers. New test files: - `Animated/__tests__/SpringAnimation-itest.js`, `DecayAnimation-itest.js`, `AnimatedColor-itest.js`, `AnimatedComposition-itest.js` — spring/decay curve shape (both drivers), `Animated.Color` value semantics, and the composition nodes (`add`/`subtract`/`multiply`/`divide`/`modulo`/`diffClamp`/tracking). `AnimatedFantomTestUtils.js` holds the shared trajectory helper. - `Components/View/__tests__/View-nativeCSSParsing-itest.js` — string-valued CSS (color functions, transform, gradients) parsed via native CSS parsing. - `Pressability/__tests__/Pressability-touch-itest.js` — press in/out/press, long press, press delay, and responder termination via touch events and the deterministic timer mock. - `Interaction/__tests__/PanResponder-itest.js` — grant/move/release/terminate and gesture state across touch sequences. - `LayoutAnimation/__tests__/LayoutAnimation-itest.js` — `configureNext`/`create`/presets applying the resulting layout. - `Network/__tests__/Network-itest.js` — synchronous `XMLHttpRequest` lifecycle and validation. Extended test files: - `Components/TextInput/__tests__/TextInput-itest.js` — `onSelectionChange`/`onSubmitEditing`/`onKeyPress`/`onEndEditing` events. - `Lists/__tests__/FlatList-itest.js` — `onViewableItemsChanged` across all `viewabilityConfig` options (`itemVisiblePercentThreshold`, `viewAreaCoveragePercentThreshold`, `minimumViewTime`, `waitForInteraction`). - `Text/__tests__/Text-itest.js` — `letterSpacing`, `lineHeight`, and `fontVariant` styles. The runtime behavior of `Animated` is unchanged; the new timing indirection defaults to `Date.now()`. Changelog: [Internal] Reviewed By: javache, zeyap Differential Revision: D110784436 fbshipit-source-id: 886c5fa735adb01b107ffba7c52c96f2a31b8909Rubén Norte · 17e55f6b · 2026-07-14
- 1.5ETVConvert `ReactHorizontalScrollView` to Kotlin (#57045) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/57045 Convert `ReactHorizontalScrollView.java` to `ReactHorizontalScrollView.kt` using idiomatic Kotlin while preserving the public API surface. Key changes: - `ReactHorizontalScrollView.java` replaced by `ReactHorizontalScrollView.kt` - `ReactHorizontalScrollViewManager.kt` updated to use Kotlin property access syntax for `scrollEnabled`, `stateWrapper`, and `fadingEdgeLengthStart/End` - Static helper methods (`findDeepestScrollViewForMotionEvent`) moved into the companion object - Public API surface preserved: only additive `synthetic` constructor from `JvmOverloads` Changelog: [Android][Changed] - Convert `ReactHorizontalScrollView` from Java to Kotlin Reviewed By: Abbondanzo Differential Revision: D107236883 fbshipit-source-id: 37fb0f646193c2fc88008196f0db6e7307332109Nicola Corti · 5c680995 · 2026-06-04
- 1.4ETVClear RuntimeScheduler queues on error (#56892) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/56892 changelog: [internal] Add `enableRuntimeSchedulerQueueClearingOnError` and use it in `RuntimeScheduler_Modern` to clear pending tasks, pending rendering updates, and pending surface IDs before forwarding task or microtask errors to `onTaskError`. Update `SchedulerDelegateInvalidationTest` so `enableSchedulerDelegateInvalidation` can be disabled while the new queue-clearing flag is enabled, proving that stale rendering updates and queued follow-up tasks are dropped after an error. Reviewed By: christophpurrer Differential Revision: D105696366 fbshipit-source-id: 24aa04a8084fb1534bb85785558b503bb8cf619cSamuel Susla · 9cbddbd4 · 2026-05-20
- 1.4ETVFormalize Text in JS as overflow: hidden by default (fixes overflow: visible text with props 2.0) (#55553) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/55553 RN components on the native side currently act like a mix of both overflow: hidden and overflow: visible, veering closer to the former in the ways that matter most. PreparedLayoutTextView lets us implement this more correctly, and either clip text to padding box, or not clip the text at all. For compat, PreparedLayoutTextView/PreparedLayoutTextViewManager defaulted to `overflow: hidden`. Props 2.0, broke this, since we need to see overflow state change in Fabric props, which defaults to Yoga blank style defaults (always `overflow: visible`). The sanest solution I could find was to change Android native view to keep same defaults as Fabric style layer, then explicitly set `overflow: hidden` at the style layer, as the default behavior. This does slightly change behavior, so that components which previously clipped at the bounding rect of their border box, now clip at their padding box. I.e. text will not be drawn over borders, or rounded corners, by default after this change. Changelog: [General][Changed] - Text is no longer drawn on top of borders by default [General][Changed] - Text outside the bounds of a borderRadius is now hidden by default Reviewed By: mdvacca Differential Revision: D93324626 fbshipit-source-id: 955975f01ca0333dd135e236f26f5dab828a7491Nick Gerleman · 2111bec8 · 2026-02-20
- 1.4ETVCSS Grid 1/9: Grid style types and public API (#55876) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/55876 - Add foundational data types, enums, style properties, and C API for expressing CSS Grid layouts - Includes `GridLine.h`, `GridTrack.h`, `GridTrackType.h`, `Display::Grid`, new alignment enums (`Align::Start/End`, `Justify::Auto/Stretch/Start/End`) - C API: `YGGridTrackList.h/cpp`, `YGNodeStyle` grid setters/getters - Layout helper updates, `Node.h` `relativePosition` made public Split from https://github.com/facebook/yoga/issues/1865. Part of the CSS Grid implementation series. Changelog: [Internal] X-link: https://github.com/facebook/yoga/pull/1893 Reviewed By: sammy-SC Differential Revision: D94867121 Pulled By: NickGerleman fbshipit-source-id: adcb6d107cdd782550a614f87f84cff3ecefd806nishan (o^▽^o) · 26cef641 · 2026-03-05
- 1.4ETVConvert to Kotlin - ReactEditText Summary: This diff converts the last java file inside `com.facebook.react.views.textinput` to Kotlin. As `ReactEditText` is quite involved, reviewing this one is going to be quite critical. I'm marking this as breaking as a number of nullability types has changed for OSS users. Changelog: [Android] [Breaking] - com.facebook.react.views.textinput.ReactEditText is now in Kotlin. If you're subclassing this type you'll need to adjust your signatures. Reviewed By: rshest Differential Revision: D72972921 fbshipit-source-id: 92ed112444cbc20daed5466ad20f651479bfac6fNicola Corti · cac27d15 · 2025-04-16
- 1.4ETVIntroduce V2 Perf Monitor feature flags (#52809) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/52809 **Context** Experimental V2 Performance Monitor prototype, beginning by bringing the [Interaction to Next Paint (INP)](https://web.dev/articles/inp) metric to React Native. **This diff** Add two new feature flags: - `fuseboxInteractionMetricsEnabled` — Will configure sending of interaction live metrics to CDP clients, independent of an active performance profiling session. - `perfMonitorV2Enabled` — Will enable the backend + UI for the V2 Perf Monitor. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D78894857 fbshipit-source-id: 7605357b3cc9255d76f66bde605f9e520dda9750Alex Hunt · a3e99264 · 2025-07-25
- 1.4ETVAdd feature flag to disable subview clipping (#54416) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/54416 See title Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D86262692 fbshipit-source-id: bf7fb2a45e33a0c6974af6138b3735cfeef1ae0cNick Lefever · 8123f319 · 2025-11-05
- 1.4ETVMigrate `ReactShadowNode` interface from Java to Kotlin (#56941) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/56941 Migrate the `ReactShadowNode` interface from Java to Kotlin as part of the ongoing Kotlin migration effort. This is a mechanical conversion of a deprecated legacy architecture interface with no functional changes. The interface is a pure declaration with no default implementations. Changelog: [Android][Changed] - Migrate `ReactShadowNode` interface from Java to Kotlin Reviewed By: javache Differential Revision: D106079764 fbshipit-source-id: 4b220c791fb9b912877a9a8ef5a7152b8efa3a36Nicola Corti · f07c7cce · 2026-06-02
- 1.4ETVAdd LIS-based differentiator for minimal child reordering mutations (#56094) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/56094 The current Differentiator Stage 4 uses a greedy two-pointer algorithm to reconcile reordered children. When children are shuffled, it produces excessive REMOVE+INSERT pairs because it doesn't find the minimal edit. This adds an alternative code path that uses Longest Increasing Subsequence (LIS) to identify which children can stay in place vs which need to be moved. Items in the LIS maintain their relative order — only items outside the LIS need REMOVE+INSERT. Example: moving last element to front [A,B,C,D,E] → [E,A,B,C,D]: - Greedy: 4 REMOVEs + 5 INSERTs = 9 mutations - LIS: LIS=[A,B,C,D], only E moves = 1 REMOVE + 1 INSERT = 2 mutations The LIS algorithm is O(n log n) time, O(n) space. Since average child count is <10, the position mapping uses linear scan instead of hash tables. Guarded by `useLISAlgorithmInDifferentiator` feature flag (default off). Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D96334873 fbshipit-source-id: a417d6b74a3195b3ff3cb98e76d4820073918c2bPieter De Baets · 44ac8c26 · 2026-03-16
- 1.3ETVExecute commands in order (#54074) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/54074 Currently, we dispatch view commands eagerly at the beginning of a batch. This behavior originated with https://github.com/facebook/react-native/commit/b54257c628b1a174a2c41960e7fc4d2d719ad731. However, this can make it difficult to allow developers to control mount item execution order. For example, someone may want to make sure a view command is processed *after* a particular mount item, and not exclusively rely on retryable command exceptions. This change sets up a feature flag to enable in-order execution of view command mount items. ## Changelog [Internal] Reviewed By: mdvacca, sammy-SC Differential Revision: D84061054 fbshipit-source-id: 7cb68c43823ed67f541f4e8f2d7471629609a905Eric Rozell · 8cc9bbc8 · 2025-10-09
- 1.3ETVConvert com.facebook.react.runtime.ReactHostImpl to Kotlin (#51017) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/51017 Changelog: [Internal] Reviewed By: rshest Differential Revision: D73846053 fbshipit-source-id: 98017000e8f10df4156b232bc8b5d6e132502ea5Pieter De Baets · 54133045 · 2025-05-12
- 1.3ETVMigrate `UIManagerModule` from Java to Kotlin (#56996) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/56996 Migrate `UIManagerModule` from Java to Kotlin as part of the ongoing Kotlin migration effort. This is a mechanical conversion of a deprecated legacy module with no functional changes. Changelog: [Android][Changed] - Migrate `UIManagerModule` from Java to Kotlin Reviewed By: javache Differential Revision: D106080563 fbshipit-source-id: 2d0b21cc26c50e1e026b579e4adcee7e71a2be18Nicola Corti · 21dfc2a8 · 2026-06-02