The marketing department needs weekly changes to the home screen, but App Store Review takes 2–3 weeks. In our practice, we have encountered this dozens of times. The solution is Server-Driven UI (SDUI), a pattern where the server delivers not only data but also a description of how to display it. The mobile client becomes a universal renderer that dynamically builds screens from a JSON schema. Our experience: over 5 years in mobile development and 20+ SDUI projects. Companies like Airbnb (Ghost Platform, as described in Airbnb Engineering Blog) and Mercado Libre already use this approach on most screens, and we have implemented it for several retail projects.
How Server-Driven UI Works
The server stores the component tree for each screen. The client receives a JSON description and recursively renders components from its registry. For example, for the home screen, the structure arrives:
{ "version": "1.0", "screen": { "type": "scroll_view", "children": [ { "type": "hero_banner", "props": { "imageUrl": "...", "title": "Summer Sale", "action": { "type": "navigate", "route": "/sale" } } }, { "type": "product_grid", "props": { "columns": 2, "dataSource": { "endpoint": "/api/products/featured" } } } ] } } The component system is a registry of types: hero_banner, product_grid, text_block, cta_button, carousel. A new component type is added on the server and clients simultaneously, deployed via App Store/Play Store with a new app version.
Why This Is Harder Than It Seems
- Schema versioning. Users update the app slowly. If the server sends
"type": "new_component"and client version 2.1 doesn't know it, the screen will crash or display incorrectly. A strategy is needed: fallback component, minimum supported version, graceful degradation. - Typing and validation. Without a strict schema (JSON Schema, Protobuf,
kotlinx.serializationwith sealed classes), the server might send an invalid payload, and the crash will be on the client instead of where the error occurred. On iOS —CodablewithDecodingStrategy.useDefaultValues, on Android —@SerialName+ sealed class with@JsonClassDiscriminator. - Parsing performance. A complex screen in JSON is 5–50 KB. This is not recalculated on every scroll, but cold render on first open and schema caching are separate engineering tasks.
Server-Driven UI vs Traditional UI: Comparison
| Characteristic | Traditional UI | Server-Driven UI |
|---|---|---|
| Time for UI changes | Weeks (release) | Hours (server fix) |
| Update frequency | Every 2–4 weeks | Daily |
| Dependency on App Review | Yes | No |
| Development complexity | Lower | Higher (engine + versioning) |
| Flexibility for A/B tests | Limited | Full |
On average, SDUI reduces change deployment time from weeks to hours, 10x faster than traditional approach. Several clients saved over 40 development hours per month.
When to Use Server-Driven UI?
SDUI is justified when:
- Frequent layout changes without app release (marketing banners, promo screens, onboarding)
- A/B tests at screen level: server sends different schemas to different user segments
- Multiple brands in one app: white label where each client sees their own screen
- Strong editorial team: CMS interface allows non-technical staff to change screens
Note: SDUI is not needed when: app with stable UI, small team, no business requirement to change screens without App Store release.
Versioning Scheme: Fallback Components
| Schema version | Component type | Action on old client |
|---|---|---|
| 1.0 | hero_banner | Renders as is |
| 1.5 | video_banner | Fallback to image_banner |
| 2.0 | interactive_map | Fallback to text_block with link |
Real Case from Our Practice
A retail app on iOS and Android. The marketing team wanted to change the home screen (banners, categories, recommendations) weekly — without waiting 2–3 weeks for App Store Review. We implemented SDUI in stages: first only the home screen (Hero Banner + Category Grid), after three months — category pages and product cards. Backend — CMS on Laravel with a visual schema editor. Client — iOS SwiftUI, Android Jetpack Compose. After 4 months, marketing publishes new screens independently without mobile developer involvement. Our client saved over 40 development hours per month.
Infrastructure and CDN
Screen schemas are cached on CDN (CloudFront, Fastly) with Cache-Control: max-age=300. Invalidation via stale-while-revalidate — the user immediately sees a cached version, fresh one loads in background. For critical changes — Surrogate-Key for targeted invalidation of a specific screen.
What's Included in the Work
- Schema documentation: description of all components, their props, and versioning
- Reference client implementation on one platform (iOS or Android)
- Code review and integration into existing project
- Team training (up to 2 days) on using the SDUI system
- Support during launch phase (2 weeks)
- SDUI setup for your stack: SwiftUI, Jetpack Compose, Flutter
Timelines: basic SDUI system (3–5 component types, one screen) — 4–6 weeks. Full platform with CMS editor, A/B testing, schema versioning — 12–20 weeks.
We guarantee compatibility with your stack. Contact us for a free project assessment — we will analyze your current architecture and propose a plan. Request a consultation to discuss SDUI implementation details for your app.