RemoteCompose Is Now AndroidX: What This Means for Server-Driven UI

But RemoteCompose takes a fundamentally different approach than what most teams think of as server-driven UI. Understanding the distinction matters if you're evaluating your options.

What RemoteCompose Actually Does

RemoteCompose doesn't send a component description (like JSON) to the client. Instead, it captures drawing operations — the actual render commands — and encodes them into a compact binary format (.rc files).

Here's what that means in practice:

Server side (plain JVM, no Android SDK)

val writer = RemoteComposeWriter()
writer.document {
    column(modifier = Modifier.padding(16.dp)) {
        text("Hello from the server", fontSize = 24.sp)
        button(text = "Click me", onClick = { /* action */ })
    }
}
val bytes = writer.encodeToByteArray()

Client side (Android)

val player = RemoteComposePlayer(context)
player.setDocument(downloadedBytes)
player.setClickHandler { action -> handleAction(action) }

The client doesn't need to know what a "button" is. It just executes drawing instructions. Think of it like streaming a video of your UI — but natively rendered.

This is clever. It's also a very specific trade-off.

Two Philosophies of SDUI

RemoteCompose represents what we'd call drawing-level SDUI: the server controls every pixel. The binary format captures layout, drawing operations, touch targets, scrolling behavior — everything.

The alternative is component-level SDUI: the server sends a description (usually JSON) of what to render, and the client maps that to its own native components. This is what Airbnb, Lyft, DoorDash, and most large-scale SDUI systems use.

Here's where they diverge:

	Drawing-Level (RemoteCompose)	Component-Level (Pyramid, Airbnb-style)
Wire format	Binary (.rc)	JSON or DSL
Client knowledge	Minimal — just plays operations	Maps to native components
Your design system	Server-defined	Client-defined (BYOC)
A/B testing	Manual	Automatic exposure tracking
Debugging	Binary inspection	Human-readable JSON
Platform support	Android only	Multi-platform possible
Analytics granularity	Screen-level	Component-level

Neither is objectively better. They solve different problems.

When RemoteCompose Makes Sense

RemoteCompose shines for specific use cases:

1. Promotional surfaces — Splash screens, feature announcements, banners that need pixel-perfect control
2. Rapid experimentation on visuals — When you want to test entirely different layouts without any client-side component work
3. Simple content screens — Info pages, settings, forms where component reuse isn't important
4. Single-platform Android teams — If iOS isn't in your roadmap

The binary format is compact and fast to render. Google backing means it'll integrate well with the Compose ecosystem. And it's genuinely zero client-side UI logic — the player just renders whatever bytes it receives.

When Component-Level SDUI Makes More Sense

For teams with mature design systems, the component-level approach has advantages that compound over time:

1. Your Components, Your Quality

When your app already has a ProductCard, ReviewStars, PriceTag, and AddToCartButton — all tested, accessible, and matching your design system — you don't want to recreate those as drawing operations on a server.

Component-level SDUI says: "Render a ProductCard with these props." The client renders your component. Accessibility, animations, haptics — all preserved.

2. Analytics Without Extra Work

If the server sends {"type": "ProductCard", "props": {"id": "ABC123"}}, you automatically know:

• Which components were shown
• Which were interacted with
• How they performed in experiments

With drawing-level SDUI, you'd need to manually instrument each binary document for analytics — because the client doesn't know what it's rendering.

3. Multi-Platform

RemoteCompose is Android-only. If you ship on iOS too (most do), you need a different solution for half your user base. Component-level SDUI works the same way on both platforms — the wire format is platform-agnostic, only the rendering layer differs.

4. Developer Experience

JSON is debuggable. You can curl your layout endpoint, read the response, and understand what the screen will look like. Binary formats require specialized tooling.

With typed DSL codegen, your backend developers get IDE autocomplete and compile-time type safety:

// Generated from your component schemas
screen("home") {
    header(title = "Welcome back")
    productGrid(
        columns = 2,
        products = fetchProducts()
    )
    recommendationCarousel(
        algorithm = "collaborative-filtering"
    )
}

This catches errors at compile time, not in production.

What Google's Backing Really Means

RemoteCompose becoming AndroidX isn't just about the library — it's validation.

Google is saying: "Server-driven UI is a real pattern that deserves first-party support."

For teams evaluating SDUI, this removes the biggest objection: "Is this a real thing, or just a hack that Big Tech uses?" It's real. Google built a library for it.

But it's important to note what Google chose to build. RemoteCompose is a low-level rendering primitive. It's the SDUI equivalent of Canvas — powerful, flexible, but not opinionated about component architecture.

Most teams don't paint their UI on Canvas. They use composables, views, components. Similarly, most teams evaluating SDUI will want something that works with their existing component libraries — not a drawing-level replacement.

The Market in March 2026

The SDUI landscape is heating up fast:

• RemoteCompose (Google) — Drawing-level, Android-only, binary format
• Nativeblocks — BYOC with cloud management, now supports React Native
• Digia — Flutter-first, low-code visual builder targeting designers/PMs
• Nubank's Catalyst — Custom Flutter SDUI powering 43% of their app for 115M users
• Pyramid — Component-level BYOC with typed DSL codegen, native Android + iOS

Every one of these takes a different approach. The market is segmenting, which is healthy — it means there's no one-size-fits-all solution, and teams can choose based on their actual needs.

Making Your Choice

What's Next

Google I/O is around the corner, and RemoteCompose will likely get more stage time. We expect to see:

• Better tooling and documentation
• Potentially a web editor (community members are already building these)
• More adoption guides from the Compose team

For the broader SDUI ecosystem, Google's entry raises all boats. More awareness, more validation, more teams considering the pattern.

The question was never "will SDUI go mainstream?" — it was "when." With AndroidX backing, the answer is now.

Frequently Asked Questions

What is RemoteCompose AndroidX?

RemoteCompose is an official AndroidX library that captures drawing operations — the actual render commands — and encodes them into a compact binary format (.rc files). Instead of sending component descriptions (like JSON), the server sends binary drawing instructions that the client renders directly. It's now at alpha05 and climbing, signaling Google's commitment to server-driven UI as a first-party pattern.

What is the difference between drawing-level and component-level SDUI?

Drawing-level SDUI (like RemoteCompose) sends actual render commands in binary format — the client just plays operations without knowing what a "button" is. Component-level SDUI (like Pyramid, Airbnb-style) sends a JSON description of what to render, and the client maps that to its own native components. Drawing-level gives pixel-perfect server control; component-level preserves your design system and works cross-platform.

When should I use RemoteCompose vs component-level SDUI?

Use RemoteCompose if you're Android-only, want pixel-perfect server control, and primarily need simple content screens or promotional surfaces. Use component-level SDUI if you have an existing design system, ship on both Android and iOS, need A/B testing and experiment tracking, or want type-safe DSL authoring for your backend team.

Does RemoteCompose work on iOS?

No, RemoteCompose is Android-only. If you ship on iOS too (most teams do), you need a different solution for half your user base. Component-level SDUI works the same way on both platforms — the wire format is platform-agnostic, only the rendering layer differs.