Bootstrapping Simple Server Driven UI from a Design System Abdulahi Osoble Ahmed El-Helw 

Problems • Iteration speed is critical for business success • Mobile releases take time for adoption • Consistency on iOS and Android 

Today Mobile fetch data from APIs and bind them to UIs on the client side. 

What If Our features come from an endpoint? 

Server Driven UI Mobile fetches UI representation from APIs 

No content

Building SDUI 

Building from Scratch • Need some UI components • Need a serializable data representation 

{ "type": "label", "text": "Hello, World!" } 

data class LabelData(val text: String) @Composable fun Label(data: LabelData) { Text(data.text) } 

data class LabelData(val text: String) @Composable fun Label(data: LabelData) { Text(data.text) } 

Let's add Max Lines 

{ "type": "label", "text": "Hello, World! This is not very long ... ", "maxLines": 2 } 

data class LabelData(val text: String, val maxLines: Int) @Composable fun Label(data: LabelData) { Text(text = data.text, maxLines = data.maxLines) } 

Let's Add Typography? 

This is a lot of Work • We’d have to expose: • Text size • Colors • Typefaces • Font weights • This also starts to tie us to the underlying platform 

Can we make the problem smaller? 

Design System Already Solves this for Us 

Design System • Opinionated • Limits the landscape of what is possible • Lets us use larger building blocks • Allows us to save time 

Android • Views • Compose iOS • UIKit • SwiftUI 

Design System • Components • Foundations (types and tokens) 

Components • May not be easy to serialize / deserialize directly • Need a data representation 

Types and Tokens • Styles, Color Tokens, etc • Easy to serialize / deserialize 

Demo 

Server Driven UI • Same payload should render on iOS and Android 

Build a Serialization Layer 

Step 1 - Decide data representation of our widgets Step 2 - Render that data representation 

data class LabelData(val text: String, val maxLines: Int) @Composable fun Label(data: LabelData) { Text(text = data.text, maxLines = data.maxLines) } 

No content

interface Component data class LabelData( val text: String, val maxLines: Int ): Component 

interface Component data class LabelData( val text: String, val maxLines: Int ): Component 

How do we Render? @Composable fun render(component: Component) { when (component) { is LabelData - > Label(component) is ButtonData -> Button(component) // .. . } } 

How do we Render? @Composable fun render(component: Component) { when (component) { is LabelData -> Label(component) is ButtonData -> Button(component) // ... } } 

Can we Simplify? interface Component { @Composable fun Content(modifier: Modifier) } 

class LabelData( private val text: String, private val maxLines: Int ) : Component { @Composable override fun Content(modifier: Modifier) { Label(text = text, maxLines = maxLines) } } 

class LabelData( private val text: String, private val maxLines: Int ) : Component { @Composable override fun Content(modifier: Modifier) { Label(text = text, maxLines = maxLines) } } 

@Composable fun Sample(component: Component, modifier: Modifier) { component.Content(modifier) } 

Tradeoffs 

Share with iOS or Not? 

iOS 16 class WidgetData: ObservableObject { @Published var count = 0 } struct Widget: View { @ObservedObject var data: WidgetData var body: some View { /* ... */ } } 

iOS 17 - Observation Framework @Observable class WidgetData { var count = 0 } struct Widget: View { var data: WidgetData var body: some View { /* ... */ } } 

Other Options • Share models with KMP with a Swift wrapper • codegen Kotlin and Swift models 

import SwiftUI struct {{ widget.name }} { {% for key, value in widget.fields %} let {{ key }} : {{ value }} {% endfor %} } 

data class {{ widget.name }} ( {% for key, value in widget.fields %} val {{ key }} : {{ value }} , {% endfor %} ) 

Other Options • Share models with KMP with a Swift wrapper • codegen Kotlin and Swift models • Expect/action chicanery 

expect interface Renderer 

actual interface Renderer { @Composable fun Content(modifier: Modifier) } 

actual interface Renderer 

interface Component { fun renderer(): Renderer } 

Public API 

interface Component { @Composable fun Content(modifier: Modifier) } 

data class ServerDrivenUiResponse( val root: Component ) 

@Composable fun ServerDrivenUi( response: ServerDrivenUiResponse, modifier: Modifier ) { response.root.Content(modifier) } 

{ "root": { "type": "list", "contents": [ ] } } Example of List 

class ListComponent( private val contents: List ) : Component { @Composable override fun Content(modifier: Modifier) { LazyColumn(modifier = modifier) { contents.forEach { item { it.Content(modifier) } } } } } 

class ListComponent( private val contents: List ) : Component { @Composable override fun Content(modifier: Modifier) { LazyColumn(modifier = modifier) { contents.forEach { item { it.Content(modifier) } } } } } 

How Do We Use This? 

@Composable public fun Sample( response: ServerDrivenUiResponse, modifier: Modifier = Modifier ) { SampleTheme { Surface(modifier = modifier) { ServerDrivenUi( response, Modifier.padding(all = 8.dp) ) } } } 

What about events? 

Actions 

• Based on user interaction • Broken down in sections • Must have common super-type 

interface Action sealed class OnClick: Action { class Deeplink(val link: String): OnClick() } 

interface Action sealed class OnClick: Action { class Deeplink(val link: String): OnClick() } 

{ "actions": [ { "type": "onClick_deeplink", "link": “careem: // link“ } ] } 

{ "actions": [ { "type": "onClick_deeplink", "link": “careem: // link“ } ] } 

How do we handle Actions? 

// Public API interface ActionHandler { suspend fun onClick(action: OnClick) {} } val LocalServerDrivenUiActionHandler = staticCompositionLocalOf { error("nothing provided") } 

class LabelData( private val text: String, private val maxLines: Int, private val actions: List = emptyList() ) : Component { @Composable override fun Content(modifier: Modifier) { Label( text = text, maxLines = maxLines, modifier = modifier.handleAction(actions) ) } 

// Internal API internal fun Modifier.handleActions(actions: List): Modifier = composed { val handler = LocalServerDrivenUiActionHandler.current val scope = rememberCoroutineScope() var localModifier = this actions.forEach { action -> localModifier = when (action) { is OnClick -> localModifier.clickable { scope.launch { handler.onClick(action) } } } 

// Internal API internal fun Modifier.handleActions(actions: List): Modifier = composed { val handler = LocalServerDrivenUiActionHandler.current val scope = rememberCoroutineScope() var localModifier = this actions.forEach { action -> localModifier = when (action) { is OnClick -> localModifier.clickable { scope.launch { handler.onClick(action) } } } 

// Internal API internal fun Modifier.handleActions(actions: List): Modifier = composed { val handler = LocalServerDrivenUiActionHandler.current val scope = rememberCoroutineScope() var localModifier = this actions.forEach { action -> localModifier = when (action) { is OnClick -> localModifier.clickable { scope.launch { handler.onClick(action) } } } 

// Public API val actionHandler = object : ActionHandler { override suspend fun onClick(action: OnClick) { when (action) { is OnClick.Deeplink -> { // .... } } } } 

// Public API val actionHandler = object : ActionHandler { override suspend fun onClick(action: OnClick) { when (action) { is OnClick.Deeplink -> { // .... } } } } 

// Public API CompositionLocalProvider( LocalServerDrivenUiActionHandler provides actionHandler ) { . .. } 

Recap • Design system simplifies our scope and empowers SDUI • Actions are powerful and optional on all components • Components are serialized from payload and self render 

How about custom components? 

No content

Extensibility 

Open Deserialization 

private val componentModule = SerializersModule { polymorphic(Component :: class) { subclass(ListComponent :: class) subclass(ListItemComponent :: class) subclass(LabelComponent :: class) // ... } } private val json = Json { serializersModule = componentModule } 

Open Deserialization • Pros: • Easy to add new components • Use SDUI without depending on design system 

Open Deserialization • Cons: • Easy to bypass design system • Duplication of widgets over time • Lose the ability to change without releasing a new version of the App 

Open up Primitives 

Open up Primitives • Rows • Columns • Modifiers 

{ "type": "row", "contents": [ { "type": "column", "contents": [], "modifiers": [] }, { "type": "progressStatus", "amount": 3, "total": 10 } ], "modifiers": [] 

{ "type": "row", "contents": [ { "type": "column", "contents": [], "modifiers": [] }, { "type": "progressStatus", "amount": 3, "total": 10 } ], "modifiers": [] 

{ "type": "row", "contents": [ { "type": "column", "contents": [], "modifiers": [] }, { "type": "progressStatus", "amount": 3, "total": 10 } ], "modifiers": [] 

Open up Primitives • Pros: • Can only build on top of existing components • Can share these on the backend • Can update these without a new app update 

Open up Primitives • Cons: • More difficult to add components • May need to add more low level components 

Demo 

Tooling 

Other Ideas • Web is useful for previewing SDUI from a CMS • Drag and drop tool or other generator • ChatGPT 

To help shipping speeds really fly, We started using server driven ui, building it against our system of design, colors, fonts, and the width of each line. We agreed on data representations, approved by Android and iOS nations. We followed it with a component interface, allowing us to deserialize a polymorphic base. We realized we'd have to glean, info on the type to draw on the screen. We need to be sure iOS and Android are in sync, as time goes on, we continue to think, do we generate code from a common source, or misuse expect actual with a bit of remorse, or do we just share models in KMP, this is yet another point in our decision tree. In order to support actions like click, without code that makes us sick, we have each action containing its data, handled by a composition local sometime later. How do we allow people to add new components? Multiple solutions, each with their proponents. Allow folks to define a component type, or implement row, column, and the low level hype. Since our design system is written in Compose, run it on multiple platforms we do propose, web and desktop make a lot of sense, open up nice doors while costing a mere pence. We hope you'll check out our GitHub repo, and make server driven ui your Home Depot. 

github.com/ahmedre/sdui