Migrate one screen to server-driven UI, not your app
Build, buy & decideOpinion5 min readMiniwall team
Part of the series: Ways to change a live app without shipping a release
Pick one screen that changes often, ask for it by name from your app, and keep the old native screen as the fallback. That's the whole migration. You ship the SDK once, nothing else in the app is rewritten, and if the new screen misbehaves you can switch it off or roll it back while the old one is still there to take over.
If you're not yet sure server-driven UI belongs in your product at all, read when not to use it first. This post is for the team that has said "maybe" and wants a first step that doesn't cost a quarter.
Why one screen, not the app
A migration you can't undo is a bet. One you can undo is an experiment, and an experiment is much easier to approve. That's our opinion, and it's the main reason we'd start small.
There's a second reason that matters to whoever owns the roadmap. The value of changing a screen without a release shows up screen by screen. If one screen changes every week and the rest change twice a year, moving the whole app buys you very little on the other screens and a lot of risk on all of them.
Pick the screen
The best first screen has three traits: people ask to change it often, the people asking are waiting on engineering to do it, and it doesn't lean on the device. Copy, order of options, offers, and what to show to whom are all good signs.
| Good first screen | Leave native for now |
|---|---|
| An upgrade prompt or sale banner that marketing wants to change weekly | A camera or scanner flow |
| An onboarding step that product keeps reordering | A checkout form that takes card details |
| A cancel or feedback screen where wording is tested | Anything driven by gestures or tight animation |
| A "what's new" or announcement banner | A screen that changes twice a year |
Swipe sideways to see every column.
The last row of the right column is the easy one to miss. A screen that rarely changes isn't worth moving, however easy it would be.
The one release you can't skip
On mobile, the SDK has to ship inside a build. That is the only app release this migration asks for, and it's the same kind of release you already do. On the web it goes out with your next deploy.
Builds that don't have the SDK yet keep showing the native screen, so nobody is forced to update. And once the SDK is in, a newer screen can contain something an older SDK can't draw. In that case the older version draws that piece's fallback if the screen has one, and leaves it out otherwise. It does not crash[4].
In the code, the change is small. The screen becomes a named slot, for example upgrade_prompt, and your app asks for that name when it used to open the native screen. Which screen sits in the slot is decided later, in a dashboard[1].
Keep the old screen as the way out
This is the step that makes the project safe, and it's the one teams skip when they're excited.
Decide in advance what the app does when the new screen isn't available. The simple answer is to show the old native screen. Here is what "isn't available" can mean:
- The slot has no published screen, or the name is wrong. The app is told the screen was not found[3].
- The server can't be reached or answers too slowly. If the device has a saved copy, it's used. If it doesn't, the call fails and your code decides[3].
- Someone turned the slot off for a platform. A platform that's off gets "not found", as if the name didn't exist[1].
That last one is a useful switch. You can turn the slot off for iOS while leaving the web on, and iOS goes to the fallback path. Test it before launch, not during an incident.
Make the first change measurable
Before you move anything, write down three things from your own history: how long the last three changes to this screen waited for a release, who was waiting, and what they'd have changed in the meantime. You don't need a spreadsheet, and you shouldn't use anyone else's numbers. Your own last three are more convincing in the meeting anyway.
After the move, the number to watch is the time from "we decided" to "it's live". Miniwall's docs say a published change reaches visitors within about a minute[2]. Your real number includes review and sign-off, which is the part that should be designed on purpose.
If you want to know whether the new screen performs better than the old one, run them side by side for a short period and compare the same measure at the same time. Comparing this month to last month mixes in everything else that changed.
Decide who can publish
The first screen is where you learn how your team wants to approve changes. Don't leave this implicit. Someone needs the permission to publish, someone should look at the change first, and everyone should know how to undo it.
In Miniwall, publishing needs the Editor role, and every version that went live can be made live again from the version history[2]. Whatever tool you use, check for those two things: a permission you can limit, and a way back that doesn't require a developer.
When this isn't worth it
- You already release every few days and nobody waits. The gain is small.
- The screen is mostly device behavior, like a camera, sensors or gestures.
- Fewer than a handful of changes a year, however important each one is.
Next step
Write down the last three changes to the screen you have in mind: how long each waited, who waited, and what they wanted. If the waits are long and the screen isn't device-heavy, that's your first screen. If you can't name three changes, pick another screen.
Sources
- Miniwall docs, Placements (a named slot, platforms turned on separately) (opens in a new tab)docs.miniwall.app · accessed
- Miniwall docs, Publish and versions (publish, roll back, who can publish) (opens in a new tab)docs.miniwall.app · accessed
- Miniwall docs, Errors (what happens when a screen can't load, saved copy) (opens in a new tab)docs.miniwall.app · accessed
- Miniwall docs, Versioning (components an older SDK does not know) (opens in a new tab)docs.miniwall.app · accessed
