react-native-webview

react-native-webview is the de facto standard for embedding web content inside a React Native app. It was extracted from React Native core once the built-in WebView was deprecated, and has since grown into a far more capable component: it exposes fine-grained control over navigation interception, JavaScript injection (both before and after page load), bidirectional messaging between native and web contexts, file downloads, HTTP error handling, and dozens of platform-specific behaviors like pull-to-refresh, incognito mode, and Apple Pay support on iOS.

The library targets iOS, Android, Windows, and macOS from a single component API, with each platform backed by its own native implementation (WKWebView on Apple platforms, Android’s WebView, and WebView2 on Windows). As of the current major version it only supports React Native’s new architecture (Fabric) and requires React Native 0.76+, reflecting the project’s decision to shed legacy-architecture maintenance burden in favor of the codegen-based native module system. It is also Expo-compatible, making it usable in both bare and managed React Native workflows.

What You Get

• A drop-in <WebView> component with a unified prop API across iOS, Android, macOS, and Windows
• Fine-grained navigation control via onShouldStartLoadWithRequest and an origin whitelist to block unwanted URL loads
• Two-way communication between native and web content through injectedJavaScript, injectedJavaScriptBeforeContentLoaded, and postMessage/onMessage
• Lifecycle and error event hooks (onLoadStart, onLoadProgress, onError, onHttpError, onContentProcessDidTerminate, onFileDownload)
• Imperative methods for programmatic control: goBack, goForward, reload, stopLoading, injectJavaScript, clearCache
• Platform-specific fine-tuning props (e.g. allowsBackForwardNavigationGestures and enableApplePay on iOS, mixedContentMode and thirdPartyCookiesEnabled on Android, useWebView2 on Windows)

Common Use Cases

• Rendering hosted web pages, documentation, or marketing content inside a native app shell
• Embedding third-party checkout, OAuth, or SSO login flows that must run in a real browser context
• Rendering PDFs, SVGs, or other web-native content formats that have no native RN renderer
• Building a hybrid app that shares a web codebase for parts of the UI while the surrounding app stays native
• Bridging native app state and a web page via injected JavaScript and postMessage-based messaging

Under The Hood

Architecture

The library ships one shared logic module (WebViewShared.tsx) that implements origin-whitelist matching, the onShouldStartLoadWithRequest interception pipeline, and default loading/error renderers, while each platform gets its own top-level component (WebView.ios.tsx, WebView.android.tsx, WebView.macos.tsx, WebView.windows.tsx) that wires that shared logic into a platform-specific native host component generated via React Native’s Fabric codegen (RNCWebViewNativeComponent, RNCWebViewSpec). Native behavior lives in per-platform source trees (Kotlin/Java under android/src, Objective-C/Swift under apple/ios, C++/C# under windows), each implementing its own WebViewClient/WKWebView/WebView2 wrapper, event emitters (TopLoadingStartEvent, TopMessageEvent, etc.), and a native module (RNCWebViewModule) that resolves the async shouldStartLoadWithRequest decision back into the underlying platform WebView. Changing the shared JS layer risks behavior drift across four independently-maintained native backends, so the project leans heavily on its per-platform CI matrix to catch regressions.

Tech Stack

The package is TypeScript-first (typed via WebViewTypes.ts and platform-specific prop interfaces), built with Babel for JS output and a separate TypeScript declaration-emit step, and linted/formatted with oxlint and oxfmt rather than ESLint/Prettier. It only declares escape-string-regexp and invariant as runtime dependencies, keeping the JS footprint minimal, while react and react-native are peer dependencies. The native side depends on each platform’s own toolchain (Gradle/Kotlin for Android, CocoaPods/Xcode for iOS/macOS, MSBuild/NuGet for Windows), and the project is released via semantic-release with automated changelog generation and per-platform GitHub Actions CI (android-ci.yml, ios-ci.yml, macos-ci.yml, windows-ci.yml, lint.yml).

Code Quality

JS-side testing is limited: only two test files exist (WebViewShared-test.js, RCTWebView2NativeComponent-test.js, ~400 lines combined) covering the whitelist/URL-interception logic and Windows native component config, with no test coverage of the iOS/Android/macOS component wrappers themselves — native-side correctness instead relies on manual QA and the example app across each per-platform CI workflow. Type safety is strong throughout the shared and platform-specific TypeScript files, using discriminated unions for view state and detailed prop/event interfaces. Naming is consistent and descriptive, and the codebase enforces strict linting via oxlint with react/rules-of-hooks and react/exhaustive-deps set to error.

What Makes It Unique

Its distinguishing engineering choice is comprehensiveness rather than novelty: the component exposes an unusually large, deeply platform-aware prop surface (nearly 100 documented props) that lets host apps tune navigation, caching, cookies, media playback, and security behavior per platform rather than offering a lowest-common-denominator API. The project also made a deliberate, disruptive architectural bet by dropping legacy-architecture (Paper) support entirely in favor of the new Fabric architecture, trading short-term compatibility for a codegen-based native module system that keeps the JS and native layers in sync via a single spec file.