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

The News: RemoteCompose Joins AndroidX

As of March 2026, RemoteCompose has officially become an AndroidX library — now at alpha07 (up from alpha06 in just two weeks, with 16 API changes including RTL layout support, Canvas drawing primitives, and accessibility semantics — the biggest release yet). This isn't a side project or an experiment. It's now part of the same library family as Jetpack Compose, Room, and Navigation.

Arman Chatikyan's deep dive on Medium (featured in Android Weekly) brought this to wider attention, and the Android community is paying attention. Google is officially investing in server-driven rendering for Compose.

For teams already using server-driven UI, this is validation. For teams considering it, this is a signal worth understanding. But RemoteCompose isn't what most people think of when they hear "SDUI" — and that distinction matters.

What is RemoteCompose?

RemoteCompose is a library that lets you create Compose UI on a server and render it on an Android client. But it doesn't work the way most server-driven UI systems work.

Instead of sending a JSON tree of components (a button here, a card there, a list below), RemoteCompose captures low-level drawing operations — paths, shapes, text layout, transforms — and encodes them into a compact binary format. The client doesn't interpret components; it replays drawing commands.

Think of it this way:

• Component-level SDUI is like sending someone IKEA assembly instructions — "put a shelf here, attach a door there." The client understands what each piece is.
• RemoteCompose is like sending someone a finished painting — the client displays exactly what the server rendered. It doesn't know (or care) that there's a "button" in the image.

How RemoteCompose Works Under the Hood

The architecture has two main pieces:

1. Server-side Writer (JVM) — A JVM-based library that runs on your backend. You use it to compose UI using Compose's drawing APIs, and it serializes the result into a compact binary format.
2. Client-side Player (Android) — An Android library that receives the binary payload and replays the drawing operations natively using Compose's rendering engine.

The binary format is significantly smaller than equivalent JSON payloads. This makes it efficient for bandwidth-constrained scenarios — think Wear OS, embedded displays, or widgets where every kilobyte matters.

Two Approaches to Server-Driven UI

RemoteCompose's arrival makes it clear: there are now two distinct philosophies for server-driven UI, and they solve different problems.

Approach 1: Drawing-Level (RemoteCompose)

The server renders the UI and sends the visual result. The client is a display surface. This gives the server total visual control — pixel-perfect rendering without the client needing to understand what it's showing.

This works well for content display: cards, promotional banners, rich text layouts, or any scenario where you need exact visual fidelity and the user isn't deeply interacting with individual elements.

Approach 2: Component-Level (Pyramid, and what most teams mean by "SDUI")

The server sends a tree of typed components — buttons, text fields, lists, carousels — and the client renders them using its native component library. The server controls what appears; the client controls how it renders.

This is the approach used by Airbnb, Lyft, DoorDash, and Netflix. It's what Pyramid provides as a platform. It works well for interactive screens: forms, checkout flows, settings pages, and any UI where you need analytics on individual components, accessibility support, and A/B testing at the component level.

RemoteCompose vs. Component-Level SDUI: Full Comparison

Here's an honest, side-by-side comparison. Both approaches have real strengths — the right choice depends on your use case.

Dimension	RemoteCompose	Component-Level SDUI (Pyramid)
Abstraction level	Drawing operations (paths, shapes, text)	UI components (buttons, cards, lists)
Wire format	Binary (compact, fast)	JSON (human-readable, debuggable)
Platform support	Android only	Android (Compose) + iOS (SwiftUI)
Component awareness	None — client sees pixels, not components	Full — each component is individually addressable
Accessibility	Limited (no semantic component tree)	Native (components map to accessibility nodes)
Analytics / tracking	Manual — no built-in component identity	Automatic — track impressions, taps per component
A/B testing	Screen-level only	Component-level granularity
Design system integration	Server-side only	BYOC — uses your existing native components
IDE support	Standard Compose APIs on server	Typed DSL with autocomplete and validation
Payload size	✅ Very compact binary	Larger (JSON), but cacheable and diffable
Debugging	Opaque binary — harder to inspect	✅ JSON — readable in any HTTP inspector
Maturity	Alpha (alpha07)	Production-ready patterns (battle-tested at scale)
Backed by	Google (AndroidX)	Pyramid (independent)

Where RemoteCompose Wins

Let's be honest — RemoteCompose has real advantages in specific scenarios:

• Payload size — Binary is smaller than JSON. For bandwidth-constrained environments (Wear OS, IoT displays, widgets), this matters.
• Visual fidelity — The server has pixel-perfect control over rendering. No client-side interpretation means no "it looks different on this device" surprises.
• Simple integration for Android teams — If you're already all-in on Compose and don't need iOS, adding an AndroidX dependency is straightforward.
• Google backing — Being part of AndroidX means long-term maintenance, documentation, and ecosystem integration.

Where Component-Level SDUI Wins

• Cross-platform — Most teams ship iOS and Android. RemoteCompose doesn't help your iOS team. Pyramid renders the same server response as native SwiftUI on iOS and Compose on Android.
• Accessibility — Component-level SDUI produces a real accessibility tree. Screen readers understand your UI. RemoteCompose's drawing-level approach makes accessibility significantly harder.
• Analytics and experimentation — When your system knows "this is a checkout button" vs "these are some pixels," you can track impressions, measure tap rates, and run A/B tests at the component level. Pyramid includes automatic exposure tracking for experiments.
• Design system integration — Pyramid's BYOC (Bring Your Own Components) model means server-driven screens use your actual design system components. Your SDUI screens look and behave exactly like your hardcoded screens.
• Developer experience — A typed DSL with IDE autocomplete, compile-time validation, and human-readable JSON makes development and debugging faster. You can inspect payloads in Chrome DevTools, curl, or any HTTP client.

What Google's Backing Means for the SDUI Market

This is the most important takeaway: Google making RemoteCompose an AndroidX library validates server-driven UI as a category.

For years, SDUI was something "only big companies" did — Airbnb, Netflix, Lyft built custom systems, and everyone else assumed it was too complex. Google putting its weight behind server-driven rendering sends a clear message: this pattern is mainstream.

But RemoteCompose isn't competing with component-level SDUI. They're solving different problems at different levels of abstraction. It's like saying "Jetpack Compose competes with Retrofit" — they're in the same ecosystem but operate in different domains.

Which Approach Should You Choose?

Choose RemoteCompose if:

• You're Android-only (no iOS app, or separate iOS team with separate strategy)
• Your primary use case is displaying rich visual content (banners, promotional cards, editorial layouts)
• Bandwidth efficiency is critical (Wear OS, embedded, widgets)
• You don't need component-level analytics or A/B testing
• Your team is comfortable with alpha-stage APIs

Choose component-level SDUI (Pyramid) if:

• You ship on both iOS and Android
• You need experimentation and A/B testing at the component level
• Accessibility compliance matters (and it should)
• You want to use your existing design system components
• Debuggability is important (human-readable JSON vs opaque binary)
• You need production-ready tooling today, not next year

For a deeper comparison with DIY approaches, see our Pyramid vs. RemoteCompose vs. DIY SDUI breakdown.

Conclusion

RemoteCompose becoming an AndroidX library is genuinely exciting news for the server-driven UI space. It's Google acknowledging that mobile teams need more flexibility than "compile it into the binary and wait for app review."

But it's important to understand what kind of SDUI it is. RemoteCompose excels at server-side rendering for Android display surfaces. Component-level SDUI excels at interactive, cross-platform apps where analytics, accessibility, and experimentation are first-class concerns.

The right question isn't "RemoteCompose or SDUI?" — it's "What level of abstraction does my team need?" For most product teams shipping on iOS and Android, the answer is component-level. And that's what Pyramid is built for.