Server-Driven UI for Android and iOS
Push layout changes to production without submitting a new build. Your server controls what users see. Your Kotlin and Swift components do the rendering.
How server-driven UI works on mobile
The server sends a layout description. The SDK renders real native components using your platform's own rendering engine, not WebViews or a JavaScript bridge.
Server defines the layout
Instead of shipping UI code inside the app binary, your server sends a layout description: a JSON or DSL tree that says which components to show, in what order, with what properties.
SDK interprets and renders natively
The Nativeblocks SDK on the device reads that description and renders real Jetpack Compose (Android) or SwiftUI (iOS) components. It uses your platform's native rendering engine, not WebViews or a JavaScript bridge.
You update the server, users see changes
Edit the layout in Nativeblocks Studio or via the CLI. On the next app open, users get the new UI. The app binary never changes. No submission, no review, no wait.
Native SDUI vs WebView vs React Native
Not all server-driven UI approaches are equal. Nativeblocks renders with your platform's own UI framework, not a web engine.
| Nativeblocks SDUI | WebView-based | React Native OTA | |
|---|---|---|---|
| Rendering engine | Jetpack Compose / SwiftUI | WebView (HTML/CSS) | React Native bridge |
| Performance | Native, no overhead | Slower, especially animations | Near-native with caveats |
| Design system | Your own components | CSS-based, inconsistent on device | JS components, separate from native |
| Offline support | Layout cached on device | Requires service workers | Possible but complex |
| OTA UI update | Yes, server controls layout | Yes, reload HTML | JS bundle update only |
Implement SDUI in your Android or iOS app
Annotate your existing components, generate the DSL, deploy from the CLI.
Annotate your components
Add @NativeBlock to your existing Kotlin or Swift components. The compiler generates a typed DSL wrapper automatically.
// Mark a component for SDUI
@NativeBlock(
name = "My Button",
keyType = "MY_BUTTON"
)
@Composable
fun MyButton(...) { }
Run code-gen
nativeblocks code-gen reads your annotated components and generates the typed Kotlin or Swift DSL for composing screens.
❯ nativeblocks code-gen
Reading integrations...
✓ Typed DSL generated
✓ MyButtonBlock.kt created
Deploy frames from the CLI
Write your screen as a typed DSL file, then push it with one command. Users pick up the update on their next app open.
❯ nativeblocks frame deploy
--file home --tag v1.2
Bundling frame...
✓ Frame validated
✓ v1.2 live in production
When to use server-driven UI for mobile
SDUI solves specific problems. These are the situations where it pays off most.
Fix production bugs without a new build
A broken checkout screen is costing revenue. Push a fixed layout from the server in minutes instead of waiting 3 days for a store review.
Run A/B tests on mobile UI
Serve different layouts to different user segments directly from the server. Change which variant users see without a new release.
Different UI per market or user type
Banking regulations differ by country. Enterprise users need different dashboards. Send each segment its own layout instead of maintaining multiple builds.
Ship on a schedule, not around store reviews
Marketing needs a banner live at 9am Friday. Schedule the layout change on the server. No coordination with the mobile release pipeline.
Add server-driven UI to your Android or iOS app
Keep your Kotlin and Swift components. Add Nativeblocks, start deploying layouts from the server.