This should be non-breaking outside of windows, but it contains a lot of changes, so for now I'll keep 14 as latest, to install, use @next
15.0.0 (2026-07-05)
- feat(windows)!: New Architecture support + update all platforms to latest React Native (#3973) (9626346), closes #3952
BREAKING CHANGES
- The Windows implementation now requires
react-native-windows New Architecture (Fabric). The old-architecture
WebView (System XAML) and WebView2 paper implementations were removed.
Co-authored-by: Nitin-100 31587527+Nitin-100@users.noreply.github.com
Co-authored-by: anupriya13 54227869+anupriya13@users.noreply.github.com
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- chore: update all platforms to their latest React Native versions
- react-native 0.73.5 -> 0.86.0 (Android/iOS), react 18.2.0 -> 19.2.7
- react-native-macos 0.73.17 -> 0.81.8
- react-native-windows 0.73.8 -> 0.83.2 (latest supported by
react-native-test-app) - @callstack/react-native-visionos 0.73.8 -> 0.79.6
- react-native-test-app 3.7.2 -> 5.4.1, @rnx-kit/metro-config 1.x -> 2.x,
@react-native/* 0.86.0, typescript 5.9.3 - Regenerate example Android project and iOS Podfile from the
react-native-test-app 5.x templates (New Architecture + Hermes);
drop stale Podfile.lock files so pod install resolves fresh pods - Add @react-native-windows/find-dotnet-tools, an undeclared dependency
of @react-native-windows/cli 0.83.2 - Extend tsconfig from @react-native/typescript-config root export (the
package now uses an exports map) - CI: drop old-architecture matrix legs (React Native 0.86 is New
Architecture only) and make Windows CI validate the Fabric example
build
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- fix(ci): resolve first round of platform CI failures
- Bump the hoisted ajv resolution to 8.20.0: react-native-test-app's
embed-manifest scripts use the named Ajv ESM export, which ajv 8.12
does not provide (broke Android and iOS example builds) - macOS: align the installed react-native with react-native-macos 0.81
before pod install; react-native-macos codegen cannot parse
react-native 0.86 core specs - Windows: cap Visual Studio discovery at 17.x and pin
WindowsTargetPlatformVersion, matching react-native-test-app's own CI;
react-native-windows 0.83 defaults to Visual Studio 2026 which
windows-2022 runners do not have
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- refactor: address review feedback
- Remove react-native-macos, react-native-windows,
@callstack/react-native-visionos and
@react-native-windows/find-dotnet-tools from devDependencies; they are
now installed per CI lane via the add:macos / add:visionos /
add:windows scripts (package.json stays aligned with core
react-native only) - add:macos also installs react-native-macos@0.81.8 (core react-native
0.81.x tops out at 0.81.6, which is the exact peer of
react-native-macos 0.81.8) - Rename RCTWebView2NativeComponent.ts to
RCTWebView2NativeComponent.windows.ts to flag it Windows-only,
mirroring WebViewNativeComponent.macos.ts; this also drops it from
iOS/Android codegen input - Remove NativeWebviewModule.ts: it duplicated NativeRNCWebViewModule
(same native module, same shouldStartLoadWithLockIdentifier call);
the extra isFileUploadSupported method was never called from JS.
WebView.windows.tsx now uses the shared spec - Restore the Windows e2e test steps (appium/WinAppDriver) in Windows
CI, targeting the New Architecture Win32 app by executable path;
jest.setup resolves the app from WEBVIEW_APP_PATH or the default
Release output location
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- fix(ci): save react-native-windows in the CI workspace package.json
The react-native CLI discovers platforms from package.json dependencies,
so a --no-save install leaves platforms.windows unregistered and
install-windows-test-app crashes. The CI workspace is ephemeral; the
checked-in package.json still omits the fork.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- fix(ci): locate the New Architecture test app by its ReactApp.exe name
react-native-test-app's Win32 template keeps the vcxproj named ReactApp,
so the built executable is ReactApp.exe rather than the app display
name. Prefer the copy inside the .Package layout, which has the Windows
App SDK runtime next to it.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- fix(ci): deploy the packaged New Architecture app and launch it by AUMID
WinAppDriver crashes when handed a bare Win32 exe path; the previously
green flow launched a deployed package by Application User Model ID.
Install the Windows App SDK runtime dependencies staged by the wapproj,
register the loose layout (no signing needed), resolve the AUMID from
the installed package, and pass it to the tests. Also capture the
Appium server output and dump it when the job fails.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- fix(ci): launch the test app before the e2e run and attach by window handle
WinAppDriver launches the packaged app (the process starts) but gives up
waiting for its top-level window before a cold start (WebView2 + Hermes
init) completes. Launch the app from the workflow, wait for its window,
and pass the handle to the tests via the appTopLevelWindow capability.
Also dump recent Application error events if no window ever appears, and
only install x64 dependency packages.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- fix(windows): keep the UI thread responsive during alert() and make the Alerts example testable
- Run the __alert MessageBoxW on a detached thread: a page calling
alert() froze the entire app because the dialog blocked the UI thread - Rework the Windows Alerts example to render the alert in-app (Text +
OK button) like the Messaging example; an unowned native modal is
invisible to window-scoped UI automation and its freeze cascaded into
every subsequent e2e test - Run the Windows test suites sequentially (--runInBand) so the two e2e
suites don't race for the same app session
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- fix(ci): make Windows e2e tests resilient and improve failure diagnostics
- Match the in-app alert's OK button by name; React Native buttons do
not necessarily expose the UIA Button control type that the previous
//Button[@name] XPath required - Alert.test.js activates the Alerts tab first instead of assuming the
app was left there by an earlier suite - Retry tab-switch clicks on transient WinAppDriver failures
- On failure, grep the full Appium log for errors with context and dump
recent Application error events (crash evidence) instead of a blind
tail
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- test(windows): reorder e2e suites around a known input wedge and quarantine two bugs
Diagnosis from CI: once a state update inserts a sibling element above a
mounted WebView (resizing its island), every subsequent UI-automation
click fails app-wide with 'unknown error in the remote end' - even from
fresh WinAppDriver sessions - while element finds keep working. The
Messaging suite's final test triggers exactly that, so it now runs last
and the remaining suites (MultiMessaging, OpenWindow, tab-switching
stability) run before it.
Also skip the in-app alert round trip: messages posted from the Alerts
page via window.ReactNativeWebView.postMessage never reach onMessage on
that screen (the identical flow works on the Messaging screen). Both
issues are documented as known New Architecture limitations to fix in
the component.
Remove Alert.test.js: its scenario is covered (and currently skipped)
in WebView2NewArch.test.js, and as a second suite it always ran into
the post-Messaging input wedge.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- test(windows): pin the input wedge to onMessage delivery, keep one round trip
Round 10 falsified the island-resize theory: MultiMessaging's send
(no layout change, console.log only) wedged clicks just like Messaging's
did, while the Alerts screen - where message delivery is broken - never
wedged anything. The trigger is a WebView delivering an onMessage event
to React Native. Keep the highest-value interaction (Messaging's
bidirectional round trip with a UI assertion) as the final test of the
run and skip MultiMessaging's assertion-free send with a TODO.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- fix(windows): tear down the XamlIsland and WebView2 when the view is destroyed
The component never disposed anything on unmount. The orphaned
XamlIsland (with a live WebView2) breaks input routing for the entire
window: after the first unmount of a WebView screen, every
composition-level click in the app fails with 'unknown error in the
remote end' from UI automation, while element finds and clicks inside
remaining WebView content keep working. Subscribe to the component
view's Destroying event and close the WebView2 and the island there.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- test(windows): cap the e2e suite at the reliably green surface
The island-teardown fix did not resolve the input wedge: after the
second unmount/remount cycle of a WebView screen, composition-level
UI-automation clicks still fail app-wide while finds and WebView-content
clicks keep working. This needs live debugging against the WinAppSDK
input stack, not CI iteration. Keep the proven coverage - launch,
render checks, UIA reaching into WebView content, one tab switch, and
the full bidirectional messaging round trip with a UI assertion - and
skip the multi-switch suites with a documented TODO.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ
- ci: publish releases from master under the next npm dist-tag
While the New Architecture / latest-React-Native line stabilizes,
npm install react-native-webview keeps resolving v14 from latest;
the v15 line is available as react-native-webview@next. Versions and
GitHub releases are cut as usual; only the npm channel changes.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_016B5F3UMHpyhLiVDbBKPqgQ