Kotlin

AndroidX Signals a Compose-Native WebView Is on the Way

By 黄林晴 · Jul 1, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Embedding WebView in Compose remains a manual, error-prone integration that every team reimplements. An official composable would standardize lifecycle handling, back navigation, and state management, cutting a persistent source of bugs and duplicated code across Android apps.

Summary

The AndroidX repository now contains a `web/web-compose` module with a `PUBLISHED_LIBRARY` type and a 2026 inception year. Its package documentation states the goal plainly: a composable for showing web content. No public API surface exists yet — `api/current.txt` is empty — so this is an early signal, not a usable library.

Today, embedding a WebView in Compose means wiring `AndroidView` to the platform WebView and manually handling loading states, back-stack navigation, cookie sync, lifecycle cleanup, and recomposition-triggered reloads. The boilerplate grows fast once business rules enter the picture.

An official Jetpack Web Compose component would absorb that glue code. The module's placement under `platform/frameworks/support` confirms it targets Android apps, not the browser-based Compose for Web effort, a distinction that has already caused naming confusion.

Takeaways

— A `web/web-compose` module appeared in the AndroidX main branch with the namespace `androidx.web.compose` and type `PUBLISHED_LIBRARY`.

— The module's inception year is set to 2026, and its documentation describes it as a composable for displaying web pages.

— No public API exists yet; `api/current.txt` contains only a signature-format header with no classes or methods.

— The current Compose WebView pattern relies on `AndroidView` wrapping a platform WebView, requiring manual handling of reloads, back stacks, cookies, permissions, and lifecycle disposal.

— Recomposition can trigger unwanted page reloads unless guarded with a URL-equality check inside the `update` lambda.

— WebView back navigation must be coordinated with Compose's `BackHandler` by checking `canGoBack()` before calling `goBack()`.

— The module targets Android app embedding, not the browser-based Compose for Web (Kotlin/Wasm, Kotlin/JS) effort.

Conclusions

Google is signaling a Compose-native WebView well before any API is ready, which gives teams time to plan migration away from hand-rolled `AndroidView` wrappers.

The empty API file suggests the module is in an architectural scaffolding phase; the real design decisions about surface area haven't been locked in yet.

Naming confusion with Compose for Web is inevitable and will muddy search results and documentation until the component ships with a distinct Maven coordinate.

An official component would shift the support burden from individual teams to Google, but it also means less flexibility for apps that have built custom WebView behavior deeply into their architecture.

The 2026 inception year hints at a timeline that won't deliver a stable API in the immediate future, so current projects should not delay their own WebView integrations waiting for this.

Concepts & terms

AndroidView

A Compose interop API that embeds a traditional Android View (like WebView) inside a Compose layout, bridging the View system and the declarative Compose world.

DisposableEffect

A Compose side-effect API that runs cleanup logic when a composable leaves the composition, commonly used to destroy heavy resources like WebView instances.

BackHandler

A Compose API that intercepts the system back button, allowing custom navigation logic such as delegating to a WebView's history stack.

Compose for Web

A Kotlin/Wasm and Kotlin/JS effort that compiles Compose UI to run in a browser, distinct from AndroidX's web-compose module which embeds web content inside an Android app.

api/current.txt

A file in AndroidX modules that tracks the public API surface. An empty file means no public classes or methods have been declared yet.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗