SDUI vs Compose Multiplatform: Solving Different Problems in Mobile Development

The Confusion: Why People Compare Them

If you search "Compose Multiplatform vs server-driven UI," you'll find surprisingly little. That's because most people haven't realized they're asking the wrong question. The real question isn't which one — it's which layer.

Compose Multiplatform (CMP) answers: "How do I write my UI once and run it on Android, iOS, and desktop?"

Server-Driven UI (SDUI) answers: "How do I change my UI after users have already installed the app — without going through the app store?"

These are fundamentally different problems. But they sound similar because both involve "sharing UI" and "reducing work." That surface-level similarity creates confusion, especially when teams are evaluating their mobile architecture. We covered the SDUI vs cross-platform question broadly before — this article goes deep on the CMP-specific nuances.

What Compose Multiplatform Actually Solves

JetBrains' Compose Multiplatform extends Jetpack Compose to iOS, desktop, and web. If you already write Compose for Android, you can share 80-90% of your UI code across platforms. That's a real win:

• One codebase, multiple platforms. Your ProfileScreen Composable renders on Android and iOS.
• Shared design system. Material 3 theming, custom components, spacing — all defined once in Kotlin.
• Kotlin everywhere. Networking (Ktor), persistence (SQLDelight), state management (StateFlow) — same language, same paradigms.
• Faster feature development. Build a feature once instead of twice. QA one implementation instead of two.

CMP has matured significantly. As of 2026, production apps ship with shared Compose UI on both platforms. Basic components (text, buttons, lists, images), Material 3 theming, animations, and resource management all work well. It's a legitimate alternative to Flutter for teams already invested in Kotlin.

What CMP Doesn't Change

Here's what stays exactly the same with Compose Multiplatform:

• You still compile your app.
• You still submit to the App Store and Play Store.
• You still wait for review.
• You still wait for users to update.
• You still can't fix a broken screen without a new release.

CMP reduces development cost. It does not reduce release friction. This distinction matters enormously.

What Server-Driven UI Actually Solves

Server-driven UI solves a completely different problem: the app store bottleneck. Your backend sends a description of what the UI should look like, and the app renders it. Change the backend response, the UI changes — no release, no review, no update lag.

• Instant updates. Fix a typo, rearrange a screen, add a promotional banner — live in minutes.
• A/B testing at the UI layer. Test different layouts, copy, and flows without maintaining feature flag spaghetti.
• Personalization. Show different screens to different users based on behavior, cohort, or geography.
• Reduced release risk. Decouple UI changes from app binary changes. Ship faster with less risk.

SDUI doesn't care how your app renders components. It cares that the server decides which components appear, in what order, with what data. The rendering layer — whether native Compose, SwiftUI, CMP, or Flutter — is an implementation detail.

The Gap CMP Doesn't Close

Here's the scenario that trips teams up: You adopt Compose Multiplatform. Development speed improves. You're writing features once. Life is good.

Then your marketing team asks: "Can we change the homepage banner for a flash sale?"

Answer with CMP alone: No. You need to change the code, compile, submit to both stores, wait for review, wait for users to update. The banner change ships in 3-7 days. The sale is over.

Or your PM says: "We want to test two different onboarding flows to see which converts better."

Answer with CMP alone: Build both flows, add feature flags, compile, submit, wait. The feature flag approach works but ships dead code, grows complexity, and still requires a release for every new variant.

CMP solves the "write once" problem. It doesn't solve the "deploy instantly" problem. That's the gap.

Using SDUI and CMP Together

The most interesting architecture is the combined one. Use CMP for your static screens — settings, profile, complex workflows that change rarely and benefit from shared code. Use SDUI for your dynamic screens — home feeds, promotions, onboarding, anything that needs server-side control.

In this model, your component library is the shared foundation. Whether a screen is statically defined in your CMP codebase or dynamically composed by the server, it uses the same set of components. The SDUI architecture patterns guide covers this in depth.

The Component Bridge Pattern

Here's how it works in practice. You define your design system components in CMP's shared code. Then your SDUI layer maps server responses to those same components:

@Composable
fun ProductCard(
    title: String,
    price: String,
    imageUrl: String,
    badge: String? = null,
    onTap: () -> Unit = {}
) {
    // This component works in CMP shared code
    // AND in your SDUI component registry
    Card(
        modifier = Modifier.clickable { onTap() }
    ) {
        AsyncImage(model = imageUrl, contentDescription = title)
        Column(modifier = Modifier.padding(12.dp)) {
            badge?.let {
                Badge(text = it)
            }
            Text(text = title, style = MaterialTheme.typography.titleMedium)
            Text(text = price, style = MaterialTheme.typography.bodyLarge)
        }
    }
}

// Your SDUI registry maps "ProductCard" to the same Composable
val registry = ComponentRegistry {
    register("ProductCard") { props ->
        ProductCard(
            title = props.getString("title"),
            price = props.getString("price"),
            imageUrl = props.getString("imageUrl"),
            badge = props.getStringOrNull("badge"),
            onTap = props.getAction("onTap")
        )
    }
}

Now ProductCard can appear in a statically-defined CMP screen (hardcoded in your Kotlin code) or in a server-driven layout. Same component, same rendering, same design fidelity. The only difference is who decides it should appear — your code or your server.

SDUI Rendered Through CMP: The Tradeoffs

Some newer tools (like sdui.design) take a different approach: they build SDUI renderers on top of Compose Multiplatform. The server sends a JSON layout, and a CMP-based renderer draws it on all platforms through Skia.

This has clear appeal:

• One renderer for all platforms. Write the SDUI rendering engine once in shared Kotlin code.
• Consistent behavior. The same Skia rendering path means pixel-identical results on Android and iOS.
• Faster development. Build the SDUI infrastructure once, not per-platform.

But there are significant tradeoffs:

Skia vs Native Rendering

CMP renders through Skia on iOS — it paints pixels directly rather than using native UIKit/SwiftUI components. This means:

• Accessibility gaps. iOS VoiceOver integration is improving but not at parity with native SwiftUI. If your SDUI screens need full accessibility compliance, CMP-rendered SDUI may fall short.
• Platform behavior differences. Scroll physics, text selection, keyboard interaction — iOS users expect UIKit behavior. Skia-rendered components approximate it but don't match exactly.
• Performance overhead. Skia adds a rendering layer. For simple layouts it's negligible. For complex, deeply nested SDUI trees with animations, it's measurable — especially on older iOS devices.

The Irony of CMP-Based SDUI

Here's the subtle irony: one of CMP's limitations is that it still requires app store releases. SDUI exists to solve that exact limitation. Building SDUI on CMP means your dynamic layer inherits CMP's non-native rendering tradeoffs — the very tradeoffs that native SDUI avoids.

You're using a cross-platform abstraction (CMP) to power a server-driven abstraction (SDUI) to avoid the limitations of... cross-platform development. It works, but it's two levels of indirection where one might suffice.

Why Native SDUI Renderers Still Win

Companies like Airbnb, Lyft, and Netflix all built their SDUI systems with native platform renderers — not cross-platform ones. There are good reasons:

• Full platform fidelity. Native Compose on Android and native SwiftUI on iOS — no Skia layer, no approximations. Components behave exactly as users expect.
• Accessibility by default. Native components inherit the platform's full accessibility stack. VoiceOver, TalkBack, Dynamic Type, reduced motion — all work correctly without extra effort.
• Performance ceiling. No cross-compilation or rendering layer overhead. Your SDUI components are as fast as hand-written native code because they are native code.
• BYOC (Bring Your Own Components). Mature teams already have design system components built in native frameworks. SDUI should render those components, not replace them with cross-platform approximations.

The argument against native renderers is "you have to build two." That's true. But the SDUI renderer is a one-time infrastructure cost, and the typed DSL backend is already shared — you write the screen layout once, and both native renderers display it.

Which Do You Need?

You Need CMP (Not SDUI) If:

• Your main pain is development cost — maintaining separate Android and iOS codebases
• Your app is mostly static screens that change with releases
• Release velocity isn't a competitive concern (B2B enterprise apps with monthly releases)
• You're a small team and can't justify SDUI infrastructure
• Your app is heavily form-based with minimal dynamic content

You Need SDUI (Not CMP) If:

• Your main pain is release friction — app store reviews, slow rollouts, update lag
• You already have separate native apps and rebuilding in CMP isn't practical
• You need server-controlled A/B testing and personalization at the UI layer
• Your existing native design system is a competitive advantage you don't want to discard
• You need to fix UI bugs in production without emergency releases

You Need Both If:

• You want shared code and instant updates
• You have a mix of static screens (CMP) and dynamic screens (SDUI)
• You're building a platform where different parts have different change frequencies
• You want a shared component library used by both static and server-driven screens

Most mature mobile teams eventually need some form of SDUI, regardless of whether they use CMP. The question is how much of your app surface area should be server-driven. The SDUI readiness assessment can help you figure out where you fall.

The Future: Convergence

The Kotlin ecosystem is headed toward convergence. Compose Multiplatform will continue improving iOS fidelity. SDUI tools will get better at cross-platform component sharing. The teams that win will use both strategically — CMP for development speed, SDUI for deployment speed.

The complete SDUI framework comparison covers every option in the market today, including native and CMP-based approaches. And the build vs. buy calculator can help you estimate whether you should build your own SDUI layer or adopt a platform.