App-store review cycles are slow when the product team wants a layout change on Friday. That was the constraint behind sdui.in: update mobile UI from the server, without shipping a new binary.
This is how I structured the platform — a Next.js / React builder, PostgreSQL-backed publishing, and a Flutter SDK that turns JSON layouts into real widgets.
The problem
Client apps needed screens that change often: banners, form flows, card stacks, empty states. Every tweak used to mean a Flutter release. Rural and low-connectivity users also could not be forced onto the latest build immediately.
Server-driven UI (SDUI) flips that. The app ships a renderer. The server ships the layout.
What I shipped
- A drag-and-drop visual layout builder on Next.js and React so non-release work can happen in a browser
- A versioned publishing pipeline with validation, snapshot storage, and rollback
- A Flutter SDK that maps JSON layouts onto 30+ dynamic UI components
- Multi-tenant architecture with authentication and API security so multiple client projects stay isolated
The data layer is PostgreSQL. Layouts move over REST.
How the pieces fit
The builder is the source of truth for a layout draft. Publishing does not overwrite in place. It creates a validated snapshot, then points the tenant at that version. If a publish goes wrong, rollback is a pointer change, not a rebuild.
On device, the Flutter SDK fetches the active snapshot and walks the JSON tree. Each node becomes a widget from the component catalog. Unknown or invalid nodes fail closed so a bad payload does not take down the screen.
That split keeps release risk on the server and keeps the mobile binary stable.
Why versioning matters
Without snapshots, a bad publish is a production outage. With them:
- Drafts stay editable
- Validation runs before anything goes live
- The live pointer is explicit
- Rollback is immediate
This is the same idea as migrations or feature flags — apply it to UI.
Multi-tenant isolation
Several client projects share the platform. Auth and API boundaries keep tenants from reading or publishing each other's layouts. That is not optional once you have more than one production app on the same builder.
What I would still tighten
SDUI is only as good as the component catalog and the validation layer. The next pressure points are schema evolution (old apps, new nodes) and offline caching of the last-known-good snapshot — the same offline-first habit I use on agritech work.
If you want to see the live builder, it is at sdui.in.