In the world of app development, the push for faster updates and more dynamic user experiences is constant. Traditionally, changing even a small part of an app’s interface, like moving a button or adding a promotional banner, required a full development cycle. You had to change the client side code, test it, and submit a new version to the app stores, a process that could take days or even weeks. What if you could update your app’s look and feel instantly, without a single redeployment? This is the core promise of server-driven ui.
Put simply, server-driven ui (or SDUI) is an architectural approach where the server dictates the structure, layout, and content of the user interface. Instead of the UI being hardcoded into the client application (like an iOS or Android app), the app fetches a description of the UI from a server and renders it on the fly. This description, often a JSON payload, tells the app which components to display, in what order, and with what data.
Major companies like Meta use this technique for parts of Instagram and their other platforms to roll out changes and experiments instantly. It’s a powerful shift that turns your client app from a static blueprint into a dynamic canvas controlled by the backend.
Adopting a new architecture is a big decision, so what are the driving forces behind server-driven ui? The goals are centered on agility, consistency, and personalization.
Server-driven ui is more of a design philosophy than a specific framework you can just plug in. To implement it effectively, teams follow a few key guiding principles that reframe how they think about the relationship between the client and the server.
This principle flips the traditional development process on its head. Instead of building an API based on your database models, you start with the ideal user interface. You design your API response to perfectly match what the screen needs to display.
This is sometimes called a demand driven schema. A practical way to do this is by creating a “dream query”. This is the ideal API query you wish you could run to get all the data needed for a specific screen, perfectly structured. At Yelp, for example, engineers start building new GraphQL APIs by first writing a dream query that reflects the desired user experience. By starting with the UI’s needs, you create an API that serves the product directly, eliminating the need for complex data transformation logic on the client.
The goal here is to make the client app as simple as possible, essentially a “dumb” renderer. All the business logic, conditional formatting, and decision making should move to the server.
Any time you find yourself writing if/else statements in the client code to decide what to show, it’s a sign that logic could be moved to the server. When logic is duplicated across multiple platforms (web, iOS, Android), it multiplies the engineering effort and creates opportunities for inconsistencies. By centralizing these decisions, a single change on the backend applies everywhere instantly, keeping all clients in sync by design.
This principle is about the shape of the data your API returns. “Domain data” is raw, low level information like status codes, boolean flags, or raw numbers that the client has to interpret. “Product info” is presentation ready data that can be displayed directly.
For example, instead of sending a price as a number and a currency code (domain data), the API should send a pre formatted string like “$19.99” (product info). Instead of sending an isNewUser flag, the server can just include a “welcomeBanner” component in the response when appropriate. The server should handle all the formatting and localization, so the client’s only job is to display the strings and images it receives.
A unified design system is crucial for a successful server-driven ui implementation. A design system is a collection of reusable UI components and style guidelines that ensure visual consistency.
When all clients share this common visual language, the server can send abstract instructions like “render a primary button with this label” and trust that each client’s design system will produce a matching result. This provides a common language between the server and all clients, making the server’s instructions platform agnostic. It’s the bridge that allows a single JSON response to create a native look and feel on any device.
Now that we understand the philosophy, let’s look at the technical nuts and bolts. A server-driven ui system has distinct components on both the server and the client.
A typical server-driven ui architecture involves a clear separation of concerns.
"ProductCarousel") to the actual visual components in the app’s code. The client receives the JSON, loops through it, and uses the registry to instantiate and display the correct UI elements.For the client to render anything, the server needs to describe the UI using a shared vocabulary of components and actions.
Component modeling is how you represent visual elements like buttons, lists, and banners in your API. You can use an explicit type model, where every component has a specific type in your schema (e.g., ButtonComponent, ImageComponent). This is very clear and type safe. Or, you can use a more flexible generic descriptor model. This is what Yelp’s CHAOS framework evolved to use, where components are described by a type string (like "chaos.button.v1") and a generic JSON payload of parameters. This avoids constant schema changes every time a new UI element is introduced.
Action modeling defines what happens when a user interacts with a component, like tapping a button. Just like components, actions can be modeled explicitly (OpenUrlAction, NavigateToScreenAction) or generically (actionType: "chaos.open-url.v1"). The server includes these action definitions with the components, telling the client exactly what to do upon user interaction, making the dynamic UI fully interactive.
How you structure your API schema is key to making your server-driven ui flexible and maintainable. If you’re using GraphQL, you can define your UI capabilities directly with GraphQL types.
A common pattern is to use union types or interfaces. For example, a screen’s content area could be a union of ProductList, ProductCarousel, or ErrorMessage. The server decides which type to send back, and the client’s query is prepared to handle any of them. This allows the UI to be highly dynamic, changing its entire structure based on the available data or user context. The schema can also be designed to mirror the UI’s hierarchy, with a root UIScreen type that contains fields for navbar, body, and footer, each containing more components.
Both GraphQL and REST can be used to deliver UI configurations. GraphQL is often favored because its typed schema helps prevent breaking changes and its single endpoint can aggregate data from many sources efficiently.
However, a purely GraphQL approach can have drawbacks. Client queries can become very large and verbose, listing every possible field for every component. Yelp’s team found that maintaining explicit GraphQL types for hundreds of components was impractical. Their solution was a pragmatic hybrid: they use GraphQL as the main API “envelope” for high level structure, but embed REST like JSON objects for the individual components and actions. This gives them the flexibility of JSON for fast iteration while retaining the safety and structure of GraphQL for the overall API.
Implementing server-driven ui is a journey. It requires careful planning, the right tools, and a shift in mindset.
You don’t need to rebuild your entire application at once. The best approach is to adopt server-driven ui incrementally.
Start with a single screen or even just one component, like a promotional banner. You can also kickstart with a template to move faster while you learn. This allows your team to learn the process in a controlled scope. You can also apply SDUI only to new features, leaving legacy parts of the app untouched. This phased approach balances innovation with stability. There is an initial overhead in setting up the infrastructure, but starting small helps manage this complexity and delivers quick wins.
To be successful with server-driven ui, a few things need to be in place.
Some large organizations, like Yelp, build their own internal SDUI framework to serve their specific needs. Designing a framework like Yelp’s CHAOS is a massive undertaking, requiring dedicated teams to build the backend services, client SDKs, and documentation.
For many startups, agencies, and even enterprise teams, building a custom framework from scratch is not feasible. This is where visual development platforms come in. Modern tools can deliver many of the same benefits, like rapid UI updates and dynamic experiences, without the heavy engineering lift. For example, a platform like WeWeb allows you to visually build production‑grade applications that can be updated instantly, aligning perfectly with the agility that server-driven ui promises. It provides the power of a dynamic, configurable UI in a more accessible, no code environment.
Let’s look at how these concepts are applied in the real world. For more real‑world projects, explore the WeWeb showcase.
CHAOS, which stands for “Content Hosting Architecture with Optimization Strategies,” is Yelp’s unified, cross platform framework for server-driven ui. It was created to consolidate multiple disparate SDUI efforts into a single system that serves web, iOS, and Android clients. One of its key goals is to enable optimization and experimentation, allowing teams to use machine learning to automatically determine the best UI layout to show a user. The name reflects the philosophy that small, server side changes can have big, positive results on the user experience.
So how does a request flow through the system?
This model transforms the development cycle, decoupling visual changes from slow, monolithic client releases.
What is the main benefit of server-driven ui?
The primary benefit is agility. It allows teams to update, test, and personalize an application’s user interface instantly without requiring users to download a new version from an app store.
Is server-driven ui only for mobile apps?
No, while it’s extremely valuable for mobile apps due to app store delays, the principles apply to any client, including web applications. A unified server-driven ui framework can ensure UI consistency across web, iOS, and Android platforms from a single source of truth.
Does SDUI replace traditional UI development?
Not entirely. It’s a powerful approach that complements traditional development. Teams often apply it to screens that change frequently or require personalization, while more static parts of the app, like a settings screen, might remain hardcoded.
What are the downsides of server-driven ui?
The main trade offs include increased initial complexity, a dependency on network connectivity, and potential performance overhead if not managed carefully. A well designed system needs fallbacks for offline states and must be optimized for low latency.
How is server-driven ui different from a web page?
While both load content from a server, a server-driven ui app renders native platform components (like native iOS or Android widgets), providing a high performance, native user experience. A web page renders HTML in a web view. SDUI gives you the dynamic nature of the web with the performance and feel of a native app.
Can I build a server-driven ui without extensive coding?
Yes. While building a custom framework from the ground up requires significant engineering, modern visual development platforms abstract away much of this complexity. Tools like WeWeb empower you to build applications visually, where the UI can be updated and configured centrally, achieving the core goals of server-driven ui in a low code or no code paradigm.
