Pyramid vs RemoteCompose vs DIY: Choosing the Right Server-Driven UI Approach for Jetpack Compose

Server-Driven UI is no longer a Big Tech secret. But in 2026, the question isn't whether to use SDUI — it's which approach to choose. This guide compares three paths: Pyramid, RemoteCompose, and building your own from scratch.

Quick Comparison

What Is Server-Driven UI?

Before comparing, let's align on what SDUI actually means. It's a pattern where:

1. Your backend defines what the mobile screen looks like (as JSON or a DSL)
2. Your mobile app renders that definition using native components
3. You update screens by changing the backend response — no app release needed

The key insight: your app becomes a rendering engine for backend-defined layouts. This decouples what users see from when you last published to the App Store.

Option 1: Pyramid — SDUI as a Platform

Pyramid takes the approach that your team shouldn't have to build SDUI infrastructure. It provides the full pipeline:

How It Works

1. Annotate your Compose components with @PyramidBlock
2. KSP extracts schemas automatically at build time
3. Schemas sync to Pyramid's server via CLI (pyramid sync)
4. Backend developers get generated, type-safe Kotlin DSL or TypeScript SDK
5. Compose UI renders the server response using your registered components

// Your existing component — just add the annotation
@PyramidBlock(keyType = "PRODUCT_CARD")
@Composable
fun ProductCard(
    @PyramidProp(required = true) title: String,
    @PyramidProp price: Double?,
    @PyramidEvent onTap: () -> Unit
) {
    // Your existing Compose code, unchanged
}

// Backend: type-safe DSL generated from your components
val homeScreen = pyramid {
    column {
        productCard(
            title = "Premium Widget",
            price = 29.99,
            onTap = navigate("/products/123")
        )
    }
}

Strengths

• BYOC (Bring Your Own Components): Uses your actual design system, not a generic component library
• Type safety end-to-end: KSP → Schema → Generated DSL means compile-time errors, not runtime crashes
• A/B testing built in: "Live Values" let you experiment on any screen property without extra tooling
• Cross-platform: Supports both Jetpack Compose and SwiftUI natively
• Visual editor: Non-engineers can compose screens from your registered components

Trade-offs

• Commercial product (subscription pricing)
• New tool to add to your stack
• Schema extraction requires annotation adoption

Option 2: RemoteCompose — Open-Source Compose-to-Document

RemoteCompose takes a fundamentally different approach. Instead of defining a component schema, it serializes Compose layout trees into a portable document format.

How It Works

1. Author layouts in Compose on the server (or a content tool)
2. Serialize the layout tree into RemoteCompose's binary format
3. Client renders the document natively, mapping to real Compose primitives

The key innovation is that you're writing actual Compose on the server side, not JSON. The library handles serialization/deserialization.

Strengths

• Free and open-source (Apache 2.0)
• Write real Compose — no JSON/DSL translation layer
• Backed by Stream — used in production chat applications
• Lightweight — focuses on layout rendering, not a full platform

Trade-offs

• Compose only — no SwiftUI or cross-platform support
• Limited component set — you use RemoteCompose's primitives, not your own components
• No experimentation — you'd need to build A/B testing separately
• No visual editor — it's a library, not a platform
• Binary format — harder to debug than JSON

Option 3: DIY — Build Your Own SDUI

The third option is building SDUI from scratch. This is what most Big Tech companies did (why companies like Airbnb use SDUI's Ghost, DoorDash's Foundry, Lyft's SDUI, and Nubank's Catalyst). It's also what many teams attempt — with varying degrees of success.

How It Works

1. Define your JSON schema for representing UI trees
2. Build a renderer that maps JSON nodes to Compose components
3. Write backend logic to produce the JSON
4. Deploy server changes to update the UI

A Minimal DIY Renderer

@Composable
fun ServerDrivenRenderer(node: JsonObject) {
    when (node["type"]?.jsonPrimitive?.content) {
        "column" -> Column {
            node["children"]?.jsonArray?.forEach {
                ServerDrivenRenderer(it.jsonObject)
            }
        }
        "text" -> Text(
            text = node["content"]?.jsonPrimitive?.content ?: ""
        )
        "button" -> Button(
            onClick = { /* handle action */ }
        ) {
            Text(node["label"]?.jsonPrimitive?.content ?: "")
        }
    }
}

Strengths

• Full control — you own every decision
• No vendor dependency — it's all your code
• Custom to your needs — built for exactly your use case
• Free (in licensing terms)

Trade-offs

• Engineering time — plan 3-6 months for a production-quality system
• No type safety — JSON is stringly-typed by default; building type safety is a project in itself
• Maintenance burden — schema evolution, backwards compatibility, versioning
• You build everything — actions, navigation, state, A/B testing, analytics, previews
• Knowledge concentration — when the SDUI engineer leaves, who maintains it?

The Hidden Costs

The "free" in DIY is deceptive. Here's what teams typically discover:

Decision Framework

Choose Pyramid if:

• ✅ You have an existing Compose/SwiftUI design system
• ✅ You want type-safe server-driven UI without building infrastructure
• ✅ A/B testing and experimentation matter to you
• ✅ You need both Android AND iOS support
• ✅ Your backend is Kotlin or TypeScript
• ✅ You want a visual editor for non-engineers

Choose RemoteCompose if:

• ✅ You only target Android (no iOS needed)
• ✅ You prefer open-source
• ✅ Your use case is lightweight (dynamic cards, promo banners)
• ✅ You don't need A/B testing or analytics built in
• ✅ Binary format doesn't concern you

Build Your Own if:

• ✅ You have 3+ platform engineers to dedicate
• ✅ You have unique requirements no tool addresses
• ✅ You need deep integration with proprietary backend systems
• ✅ You're a large company with long-term maintenance capacity
• ✅ You've evaluated existing solutions and confirmed they don't fit

The Bigger Picture

The SDUI landscape in 2026 looks very different from even two years ago. The pattern has moved from "Big Tech secret" to an emerging ecosystem of tools and frameworks.

The right choice depends on your team's size, platform targets, and how much infrastructure you want to own vs. buy.

For most mobile teams starting with SDUI today, the question is: how quickly do you need to be productive?

If speed and cross-platform support matter, a platform like Pyramid removes months of infrastructure work. If you're exploring SDUI on a single-platform project, RemoteCompose offers a lightweight entry point. If you're building for the long haul and have the team for it, DIY gives you maximum control.

Whatever you choose — the days of waiting 2 weeks for a button color change are over.