AndroidX Signals a Compose-Native WebView Is on the Way
The latest AndroidX main branch already includes the web/web-compose module. The directory is at platform/frameworks/support/web/web-compose, and the package documentation reads web.compose, with the purpose of providing a composable for displaying web pages. Currently, api/current.txt has no public classes yet, so it looks more like a freshly surfaced Jetpack Web Compose signal.
Source Code Signal
What was spotted this time is a new directory in the AndroidX repository:
platform/frameworks/support/+/refs/heads/androidx-main/web/web-compose/src/main/kotlin/androidx/web
Under this directory are api, build.gradle, and src. Inside src/main/kotlin/androidx/web, there is currently only one documentation file, with very brief content: the module name is Web Web Compose, the package name is web.compose, and the description is to provide a composable for displaying web pages.
Three things can be confirmed from build.gradle:
android {
namespace = "androidx.web.compose"
}
androidx {
name = "web:web-compose"
type = SoftwareType.PUBLISHED_LIBRARY
inceptionYear = "2026"
}
The PUBLISHED_LIBRARY here indicates that the module is built according to the AndroidX published library approach. The namespace is androidx.web.compose, and the module name is web:web-compose. However, this does not equate to an available version on Maven, nor can the final dependency coordinates and class names be deduced.
More critically, there is api/current.txt. Currently, this file only has the signature format, with no public API at all:
// Signature format: 4.0
So at this stage, do not write that "some Web composable is already usable." What can be confirmed is only that the module has entered the AndroidX main branch, and the public interface has not yet surfaced.
The Current Approach
In Jetpack Compose, the most common way to display web pages is still AndroidView + WebView. Compose handles the layout and state, while the actual rendering of the web page is still done by the platform WebView.
A minimal wrapper looks roughly like this:
@Composable
fun WebPage(
url: String,
modifier: Modifier = Modifier,
) {
var webView: WebView? by remember { mutableStateOf<WebView?>(null) }
AndroidView(
modifier = modifier.fillMaxSize(),
factory = { context ->
WebView(context).apply {
webViewClient = WebViewClient()
settings.javaScriptEnabled = false
loadUrl(url)
webView = this
}
},
update = { view ->
if (view.url != url) {
view.loadUrl(url)
}
}
)
DisposableEffect(Unit) {
onDispose {
webView?.destroy()
webView = null
}
}
}
This code works, but it just stuffs a View into Compose. Page loading state, error pages, back stack, file selection, permission requests, cookies, dark mode, scroll conflicts, and lifecycle release all have to be handled manually. Writing a simple embedded web page is fine, but turning it into a business component will start to bloat the code.
The Boundaries of WebView
WebView is not an ordinary Compose node. It has its own process, rendering, cache, history stack, and lifecycle. Compose's recomposition only affects the update of AndroidView and does not automatically understand the web page state.
The easiest trap to fall into is repeated loading. The update block has a chance to execute on every recomposition; if loadUrl(url) is called directly inside it, list scrolling, state changes, or parent node recomposition can all cause the web page to reload. The code above uses if (view.url != url) precisely to avoid meaningless refreshes.
The second issue is release. The resources held by WebView are heavier than a regular View, with JS, images, videos, and caches inside the page. If the WebView is not destroyed when the Composable leaves the page, memory and background behavior can become very hard to troubleshoot.
Then there is back navigation handling. Compose pages typically use BackHandler to intercept the system back button, but WebView has its own history stack. In actual business logic, you often need to first check canGoBack(), call goBack() when the web page can go back, and exit the current Compose page when the web page has no history.
BackHandler(enabled = webView?.canGoBack() == true) {
webView?.goBack()
}
This code itself is not complicated; the trouble is that every project adds another layer of business rules. For example, which domains are allowed to open, what to display when loading fails, how to sync login cookies, and how to pass the web page title back to the top bar. The final wrapped component is often no longer a simple AndroidView.
The Name Is Easy to Misread
The name Jetpack Web Compose is easily confused with Compose for Web. The latter is the Kotlin/Wasm, Kotlin/JS line, targeting UI in the browser. This web-compose directory in AndroidX appears under platform/frameworks/support, and the description text also points to "a composable for displaying web pages."
Judging from the existing source code, it looks more like a component for displaying web content in Android apps using Compose, rather than compiling Compose UI to the Web platform. This boundary must be clearly distinguished, otherwise it is very easy to mix up the two technical directions.
For Android developers, it might fill the gap in the wrapper layer between AndroidView + WebView. The WebPage, ComposeWebView, and WebViewContainer that people write themselves now all have a chance to have some of their repetitive code converged by an official component. But to what extent it will be converged depends on when the API file appears.
Finally
web/web-compose has already appeared in the AndroidX main branch, and the module description points to "a composable for displaying web pages," but the current API file is still empty.
I believe many people are looking forward to the Compose version of WebView!