What is server-driven UI?
Used in a sentence: If the offers section were server-driven, we could reorder the home screen for the sale tonight instead of waiting for the next release.
How it works
The app ships with a library of native components: cards, carousels, banners, buttons, lists. Each one knows how to draw itself from a set of properties.
When a user opens a screen, the app asks the server what to show. The server replies with a structured payload, usually JSON, that names the components, their order, their content and the action each tap should trigger. The app maps each entry to its native component and renders the screen.
The server can tailor that payload by segment, experiment variant or time of day. If the network is slow, the app falls back to a cached or bundled layout. Business logic and new component types still need a release; layout and content changes do not.
Example
A quick commerce app wants a festival section on its home screen for one weekend. With client-driven UI, that means a build, store review and users updating in time. With server-driven UI, the merchandising team changes the home screen payload: a banner at the top, a carousel of sweets, a countdown widget. Every user on a recent app version sees it the next time they open the app, and it is removed on Monday the same way.
Server-driven UI vs client-driven UI
| Server-driven UI | Client-driven UI | |
|---|---|---|
| Where layout lives | On the server, as data | In the app’s compiled code |
| Shipping a change | Update the payload | Build, review, wait for updates |
| Offline behaviour | Needs caching and defaults | Works from the bundle |
SDUI is also different from code push or OTA updates. OTA swaps app code bundles, for example in React Native, while SDUI sends data that describes UI for native components the app already ships.
Best practices
- Version the payload schema so older app versions ignore components they don’t know instead of crashing.
- Always bundle a default layout and cache the last good response for slow or offline sessions.
- Start with screens that change often, such as home, offers and onboarding, rather than converting the whole app.
- Log which layout version each user saw so experiments and analytics stay readable.
How to do this with Digia Engage
Digia Engage itself works on server-driven principles: nudges, widgets and surveys are defined in a dashboard and rendered natively by the SDK, so they change without a release. For teams that want whole screens server-driven, Digia Studio provides server-driven UI for Flutter and Android, with screens built visually and published from the server. For the architectural case, read why server-driven UI matters for scalable apps.
Frequently asked questions
- Is server-driven UI allowed by the App Store and Play Store?
- Generally, yes. Rendering layouts sent by a server using native components that already ship inside the app binary is a common and widely accepted pattern. What store rules restrict is downloading new executable code that changes how the app behaves. Teams should still review the current store guidelines for their own use case.
- Does server-driven UI hurt performance?
- It can if built carelessly, because the app waits on a network response before drawing a screen. Well-built systems cache the last layout, ship sensible defaults in the binary, keep payloads small and render with native components, so screens feel as fast as hard-coded ones. Measure render time on low-end devices before rolling out widely.
- Which companies use server-driven UI?
- Large consumer apps in travel, e-commerce, food delivery and streaming have publicly described their server-driven UI systems. Airbnb and Lyft, for example, have written about their approaches. The pattern is most common where many teams change the same screens often and waiting for app store releases slows down experiments and merchandising.
Related terms
Read more
Part of the In-app engagement glossary.