Server-Driven UI (SDUI) is a pattern where the backend sends a JSON tree describing what to render, and the client maps each node to a pre-registered component. Motivated by the pain of coordinating multi-platform UI changes across web, iOS, and Android teams, the pattern moves layout decisions from clients to the API. The core implementation involves three pieces: a JSON contract with type, props, children, and actions fields; a component registry mapping type strings to React components; and a recursive renderer. Actions are encoded as data (navigate, track, add-to-cart) and dispatched via a custom hook. The post covers contract versioning for backward compatibility, caching considerations for personalized trees, Apple App Store compliance (section 3.3.1B), and where SDUI fits best (frequently changing screens, promotional layouts, per-merchant configs) versus where it doesn't (auth flows, offline-required screens).
Table of contents
What if the API picked the layout? 🔗The JSON tree 🔗The component registry 🔗The renderer 🔗Actions are data 🔗Where this fits, and where it doesn’t 🔗The Apple problem 🔗Sources 🔗1 Comment
Sort: