Backend driven UI vs server driven UI

Backend driven UI and server driven UI name the same split. The server describes the page. The client renders native views. BDU, SDUI, backend driven, server driven: LinkedIn and Medium use them interchangeably. Treat them as synonyms, not as two products.

If you split them into two URLs with two definitions, you invent a distinction the industry does not keep. This article exists so those searches land on one explanation, then send you into the envelope.

The split that actually exists#

There is a client that owns pixels. There is a server that owns structure and copy (and often experiments). The client has a catalogue of native widgets. The payload says which widgets, in which sections, with which atoms.

What does not exist is a clean industry vote on the acronym. Airbnb's public engineering posts say server driven. Some Swift blogs say backend driven. Android posts mix both. The Mobile Native Foundation thread talks about one backend response across iOS, Android, and web. None of those posts are arguing BDU versus SDUI as a taxonomy.

Flow-UI's FAQ says it in one item: backend driven UI, API driven UI, and remote UI all describe the same split. Flow-UI is the SwiftUI form: JSON in, native views out, no WebView in the middle.

Why the names multiply#

Server driven emphasises that the document is fetched (or pushed) from a service.

Backend driven emphasises that product and backend teams compose the page, not that the transport is HTTP.

API driven emphasises the JSON contract.

Remote UI is the oldest phrase and the most likely to mean a WebView if you do not nail the renderer.

None of those words tell you whether the renderer is SwiftUI or WKWebView. Always name the renderer.

struct HostLoader: PageLoader {
    func loadPage(_ request: PageRequest) async throws -> Data {
        try await myClient.data(for: request)
    }
}

The loader is host code. The name of the pattern does not change if myClient is REST or GraphQL.

let store = PageStore(pageID: "home", loader: HostLoader(), registry: registry)

What not to invent#

Do not invent a Flow-UI product called BDU that is different from SDUI. There is one envelope.

Do not claim that backend driven means "only copy" and server driven means "full layout". Teams use both phrases for full layout.

Do not claim Airbnb uses Flow-UI. Cite Ghost as an industry pattern: one schema, native renderers per platform.

How to write about it without duplicate pages#

Pick one primary phrase per URL. This site uses server driven UI on the homepage and in most docs. This article is the synonym page for backend driven UI. API driven and remote UI get their own short post so those queries are not orphaned, then they point here and at the envelope.

How to talk to stakeholders#

Product: "The backend composes the page from widgets we already shipped."

Design: "Tokens and layout are data. New visuals that are not a widget still need a release."

Backend: "You own a page document, not a second copy of every domain resource."

iOS: "We own the registry, PageLoader, and deeplink handlers."

If those four sentences match, the acronym on the slide can be BDU or SDUI. If they do not match, you do not have a naming problem. You have an ownership problem.

Practical consequences of treating them as one#

Versioning is the same problem: old binaries, new type strings, additive properties.

Unknown widgets are the same problem: skip or placeholder, diagnostics on the side.

Actions are the same problem: navigation as data, host handlers, no second router unless you build one.

Caching is the same problem: host PageLoader, not a magic framework cache.

Theming is the same problem: ColorData with dark_hex, or tokens through ThemeProvider.

If BDU and SDUI were different architectures, those lists would fork. They do not.

Where Swift-specific language still matters#

SwiftUI Observation, @MainActor widgets, and the registry's AnyView erasure are Swift-shaped. The synonym is industry-shaped. Keep both in the article: the name is shared, the types are not.

Questions this article should close#

Can we use both names in the docs?#

Yes, once. Then pick server driven UI as the default on this site so URLs do not fork. This post is the synonym catcher for backend driven UI.

Is BDU "more backend" than SDUI?#

No. Both imply a server that composes. Neither implies GraphQL versus REST. Transport is PageLoader.

Should we rename the GitHub repo?#

No. Flow-UI is the product. The pattern has many names. Do not rename the package every time LinkedIn invents a spelling.

Read next#

• FAQ
• SDUI for Swift: a practical definition
• Server driven UI for SwiftUI
• API reference: envelope

Backend driven UI vs server driven UI is a naming fight. The architecture is one split. Name the renderer and move on.