State of SDUI Before Google I/O 2026: What Every Mobile Developer Should Know

Google I/O 2026 is six weeks away (May 19–20). RemoteCompose is in AndroidX alpha. Nubank just revealed their SDUI serves 115 million customers. Flutter has three new SDUI packages this quarter alone. And Medium is flooded with "RemoteCompose will kill app updates" hot takes.

The server-driven UI space has never been this active — or this confusing. Before I/O adds more fuel to the fire, here's where things actually stand.

The Three Waves of SDUI

Understanding SDUI in 2026 requires understanding how we got here.

Wave 1: Internal Tools (2018–2022)

The big companies built their own. Airbnb had their "Ghost Platform." DoorDash built "Foundry" (internally called Lego). Lyft, Netflix, Uber — all had proprietary SDUI systems powering millions of screens. These were massive investments: DoorDash's system took years and a dedicated team.

The problem? Zero knowledge transfer. Every company reinvented the same wheel: JSON schema → parser → renderer → action system. The architecture patterns were remarkably similar, but the implementations were siloed.

Wave 2: Open Source Attempts (2022–2025)

Yandex released DivKit. Smaller projects like sdui.design appeared. Flutter got early experiments. But adoption was limited — the projects were either too opinionated, too complex, or too tied to specific ecosystems.

The fundamental challenge: SDUI requires deep integration with your component library. A generic solution either gives you generic (ugly) components or forces you to write adapters for every widget anyway.

Wave 3: Platform-Level Recognition (2025–Now)

This is where we are. Google putting RemoteCompose in AndroidX signals that dynamic UI delivery is becoming a platform concern, not just an application pattern. The question is no longer "should we do SDUI?" but "which flavor?"

The Current Landscape: Who's Doing What

RemoteCompose: What It Is and What It Isn't

RemoteCompose is the most discussed SDUI-adjacent technology right now, and also the most misunderstood.

What it actually is: A binary format that serializes Compose rendering operations. Think of it like a vector graphics format (SVG) but for Compose UI. The server sends binary instructions; the client renders them exactly.

What it isn't:

• Not component-level SDUI. RC doesn't map to your design system components. It operates at the drawing primitive level — rectangles, text runs, images.
• Not cross-platform. Android only, with no announced iOS or web plans.
• Not production-ready. Alpha05, with explicit warnings about API instability.
• Not the same as traditional SDUI. DoorDash's SDUI knows about "ProductCard" and "Banner." RC knows about Canvas operations.

The wave of Medium articles claiming "RC will replace app updates" misses this distinction. RC is excellent for certain use cases — dynamic promotional content, seasonal themes, A/B testing visual layouts. It's not a replacement for component-level SDUI with business logic, action handling, and analytics.

What Nubank Taught Us

The most important SDUI story of 2026 isn't RemoteCompose — it's Nubank's InfoQ talk about "Catalyst."

The numbers: 115 million customers. 43% of the app running on SDUI. 3,000+ engineers. Flutter-based tree-walk interpreter. This is SDUI at massive scale, proven in production.

Key architectural decisions from their talk:

1. Component-level, not drawing-level. They compose known widgets, not arbitrary graphics.
2. Type-safe schemas. Components have typed props validated at build time.
3. Gradual adoption. Started with a few screens, expanded to 43% over years.
4. Custom components first. They use their own design system components, not generic ones.

Nubank validates the approach that mature SDUI teams converge on: bring your own components, type-safe schemas, server-driven composition.

The Five Questions Every Team Gets Wrong

After studying internal systems at DoorDash, Nubank, Airbnb, and others, the same failure patterns emerge:

1. "Let's Build a Generic Component Library"

Every team tries this first. A universal set of components that work for any screen. Three months later, you have 200 "generic" components that are really just wrappers around your actual design system. The fix: Start with your existing components. Map them, don't replace them.

2. "JSON Is Our Schema"

Raw JSON with no type safety is a maintenance nightmare at scale. When a backend developer misspells a prop name, you get a runtime crash, not a compile error. The fix: Typed DSLs that generate validated JSON. Backend developers get autocomplete; mobile developers get guarantees.

3. "We'll Add Analytics Later"

In traditional apps, adding analytics is straightforward — you know which screen the user is on because you wrote the code. In SDUI, the screen is defined by the server. If you don't bake exposure tracking into the SDUI layer, you lose the ability to measure which server-driven variants perform better. The fix: Build analytics into the rendering pipeline from day one.

4. "We Don't Need Versioning"

App version 1.0 has 10 components. Version 2.0 adds 5 new ones. The server sends a response using a v2 component to a v1 client. Crash. The fix: Schema versioning with graceful degradation. Unknown components render fallbacks, not exceptions.

5. "We'll Handle Actions on the Client"

Actions (navigation, API calls, analytics events) are the hardest part of SDUI. Hardcoding action handlers defeats the purpose of server-driven architecture. The fix: A structured action system — navigate, dismiss, HTTP request, deep link — with composable action chains.

What to Watch at Google I/O

Based on the RemoteCompose trajectory and Android ecosystem signals:

• RemoteCompose beta? Moving from alpha05 to beta would signal Google is serious about shipping this to production apps. Watch for stability guarantees.
• Tooling announcements. Arman Chatikyan already built a web editor. Google could announce official tooling — a Studio plugin, a server-side library, or a cloud rendering service.
• Use case positioning. How Google frames RC matters enormously. "Dynamic promotional content" is different from "replace your UI layer." The framing will shape developer expectations.
• Android 17 integration. Could RC become a platform API rather than just a library? This would change the game entirely.

The Framework Decision Matrix

Choosing an SDUI approach depends on your team's specific needs. Here's how to think about it:

What You Should Do Right Now

Don't wait for I/O to make decisions. Here's actionable advice based on where you are:

If you're considering SDUI for the first time:

• Start with one non-critical screen (home feed, promotions, feature flags)
• Use your existing components — don't build new ones for SDUI
• Evaluate whether you need drawing-level (RC) or component-level (traditional SDUI)

If you already have SDUI:

• Audit your schema versioning — is it actually working?
• Check if you're tracking exposure analytics on SDUI screens
• Consider typed DSL codegen if backend devs are writing raw JSON

If you're evaluating RemoteCompose:

• Prototype with it — alpha05 is stable enough for exploration
• Don't bet production on it yet — APIs will change
• Understand the drawing-level vs component-level distinction

Further Reading

• RemoteCompose AndroidX: What It Means for SDUI
• What Is Server-Driven UI? The Complete Guide
• Build Your First SDUI Screen in Jetpack Compose
• SDUI for Enterprise Mobile Teams
• Google I/O 2026: What RemoteCompose Means for the Future of SDUI