When not to use server driven UI

Skip server driven UI for maps, heavy gestures, latency-critical canvases, and apps that change UI once a quarter. Use it for feeds, merchandising, onboarding, and experiments. The honest article is more useful than another pitch.

Jacob Bartlett quotes a Reddit thread that still holds: specialised SDUI is useful; a generic "HTML in JSON" framework is hubris. Compose and SwiftUI previews also weakened the "SDUI is always faster" claim. If one engineer can ship a SwiftUI page with a preview in an afternoon, a schema committee is not automatically a win.

The hubris case#

Re-implementing the web platform as JSON, then writing a renderer that approximates CSS, is a multi-year product disguised as a mobile framework. You will chase flexbox, rich text, and custom drawing until the team that wanted "faster merchandising" has left.

Flow-UI refuses that shape. Pages, sections, widgets. Open registry. Native views. If a surface needs MapKit, it is a widget you write, or it is not SDUI at all.

Good surfaces#

• Home feeds and merchandising grids
• Onboarding and empty states that marketing edits weekly
• Help, FAQ, and education as structured widgets (not a 40-page HTML doc)
• Cart and checkout chrome around payments you already own
• Experiments that swap order, copy, and which widget is featured
• Old-binary problems: new promo types skip on last month's app

These surfaces share a property: the catalogue of widgets is finite and already feels like your app. The backend is composing, not inventing a graphics API.

Bad surfaces#

• Map, camera, AR, game loop
• Custom drawing that must hit 60fps with a finger down
• Editors (rich text, video timeline) unless you wrap a single native editor as one widget
• Settings that change once a year and are easier as SwiftUI
• Flows whose legal or security review requires the UI to be frozen in the binary on purpose

When SwiftUI previews win#

If the page has one owner, one ship train, and no experiment platform, handwritten SwiftUI plus a feature flag is less machinery. SDUI costs a schema, a registry, diagnostics, and backend ownership. Pay that cost where the edit rate justifies it.

Feature flags toggle code you already shipped. They do not rearrange a tree of widgets you never compiled a composer for. The next post in this calendar is that comparison.

Flow-UI as a package for the good surfaces#

Install it for the slice. Register product widgets. Keep MapKit in MapKit. Do not rewrite the app as an envelope because a blog post said server driven UI is the future.

let registry = WidgetRegistry()
FlowWidgets.register(on: registry)
registry.register(PromoCardWidget.self)
 
let store = PageStore(pageID: "home", loader: loader, registry: registry)
FlowPageView(store: store)

The rest of the app can stay NavigationStack and handwritten views.

registry.register(HelpTopicWidget.self)

Cost you will pay even on good surfaces#

• A schema review when someone wants a new widget
• Backend ownership of page documents (on-call for "home is blank")
• Diagnostics in production so a malformed promo is a log line, not a war room
• Designers who can think in widgets instead of infinite Figma frames that have no type string

If you will not staff those, do not start. Handwritten SwiftUI is cheaper than a ghost CMS.

Industry pattern, not a case study#

Airbnb Ghost is a public engineering story about one schema and native renderers. It is not a claim that your startup needs Ghost. Mobile Native Foundation discussion 47 is a list of problems (old binaries, actions instead of hardcoded navigation). Steal the problems, not a cargo-cult architecture.

Questions this article should close#

Should the whole app be SDUI?#

Almost never on day one. Pick a slice. Keep maps and settings handwritten. Expand when the edit rate justifies the schema.

Is SDUI slower to build the first page?#

Usually yes. The second merchandising variant is where you get time back. If there is no second variant, stop.

Read next#

• Introduction
• FAQ
• Server driven UI for SwiftUI
• How to build server driven UI in SwiftUI

When not to use SDUI: when the surface is a canvas, a map, or a page that barely changes. Use it where composition is the product.