What is the Server-Driven UI pattern?
Instead of returning only data and letting the app decide the layout, the server returns a screen made of components, such as a header, a carousel and a list of cards, with their content and actions. The app has a library of components that it renders in whatever order and combination it is told. New screens and layouts can ship from the server, as long as they use components the installed app knows.
What problem does the Server-Driven UI pattern solve?
Mobile releases take days to get through review and weeks to reach most users, and some never update. If every layout change needs a release, experiments are slow and fixes reach users late. Moving layout decisions to the server lets teams change screens at the speed of a backend deploy and keeps different app versions consistent.
How do you implement the Server-Driven UI pattern?
- Build a library of well-tested, generic components in each app, with a schema for each one.
- Have the BFF return screens as trees of those components, with content and actions such as 'open this route' or 'call this endpoint'.
- Version the component schema, and have the server send only components the requesting app version supports.
- Give every unknown component a safe fallback, such as hiding it, so old apps degrade instead of crashing.
- Keep complex interactions, like forms with validation or animations, as native screens.
When should you use it?
- Screens change often, such as home feeds, promotions and onboarding, and app releases slow you down.
- You need the same screen to look consistent across iOS, Android and web.
When should you avoid it?
- Screens are highly interactive or rarely change, so the extra indirection buys nothing.
- You do not have the capacity to build and maintain a component library and schema on every platform.
What do you gain?
- Screens change without an app release
- Old app versions get new layouts too
- Easier experiments and personalisation
What does it cost?
- A new layer of schema and tooling to build
- Harder to debug what the user actually saw
- Generic components can feel less native
Who usually owns the Server-Driven UI pattern?
Platform and product teams. A platform team provides the building blocks, such as a library, a managed service or a standard, and each product team applies them in its own code and configuration. See how teams map to layers and patterns.
What are common mistakes with the Server-Driven UI pattern?
- Turning the schema into a general programming language, which is hard to test and easy to break.
- Sending a component an old app version cannot render, so part of the screen is blank.
- Putting business rules in screen descriptions instead of in domain services.
Server-Driven UI in practice
Airbnb
With client-driven UI, each of Airbnb's apps, on web, iOS and Android, decides for itself how to present the data it receives from the backend.
Airbnb built the Ghost Platform, a server-driven UI system in which the backend sends both the data and how to show it, controlling the UI across its web, iOS and Android apps. Screens are built from sections, which are independent groups of related UI components, along with screens that place them and actions that handle user interaction. Each platform has a native framework that renders them.
Example decision record
- Context
- The home screen changes weekly, but app releases take days to approve and weeks to reach most users.
- Decision
- Have the home screen BFF return a tree of known components, versioned by app version, instead of raw data.
- Consequences
- Layout changes ship with a backend deploy.
- Each app needs a maintained component library and safe fallbacks for unknown components.
Test yourself on Server-Driven UI
Marketing wants to rearrange the mobile home screen every week for campaigns. Each change currently needs an app release, and a third of users are on versions more than two months old. What approach fits?
2 questions involve this pattern. Practice all of them →
Saved in this browser only. See your progress →