Adaptive apps
One app, three boards, different screens — reflowed, not rewritten.
The same app runs on a tall rectangular panel and a small round one. You do not write the screen twice. Describe it once with a built-in layout, and ZephUI reflows it into whatever safe area the board reports. The one rule: read the board, never branch on its model id.
How one screen fits every board
Reflow is the default
A screen never places things by pixel. It picks one of the four built-in layouts and fills the regions with row, list and section. The layout owns the safe area, so the same description sits correctly on a tall panel and a round one — you did nothing per board.
Start here. Most screens need nothing else: compose from the pieces, let the layout place them, and the fit comes for free.
Read the safe area off the board
The safe area is a different shape on every device. Compose inside it and let the layout own it, rather than assuming any board's numbers. ZephUI layout has each board's exact figures — and the scroll rule that decides what stays reachable.
Read the board, not its name
The model id is an identity, not a design axis. Branch on it and you fork your app the day a fourth board ships. What you read instead is geometry: the board's shape, its safe area, its resolution.
ZephOS works this way itself. A round panel gets a larger baseline type ramp and tighter chrome around its curved edge — because it is round, not because of which board it is. Every rectangular board takes the same path; every round board takes the other. Two shapes, not N identities.
Never key a screen on the model id
if (model == 3) is a fork waiting to break. The next board with the same shape will render wrong, and the fix is a code change per device. Key on shape or safe area — properties every board reports — and new boards of a known shape work with no change from you.
When a screen must genuinely differ
Sometimes a round face truly wants a different arrangement than a tall list — not a reflow of the same tree, but a different tree. Branch on the shape: rectangular gets one arrangement, round gets the other. Both paths stay closed to the model id, so tomorrow's rectangular board falls straight into today's rectangular layout.
Reach for this only when reflow genuinely cannot carry the screen. A layout that fills its regions handles far more range than it looks like it should.
Images are the exception
A widget tree is a description; the renderer turns it into pixels. An image is the one thing you hand over already as pixels — a stored asset the renderer resolves and blits. So an image cut for a narrow panel is wrong on a wider one.
Read the board's resolution and push the image sized to it. Everything else in your screen scales because it was never pixels to begin with; an image is the only piece that has to know the board it lands on.