Multi-end deployment requires layout by capability, not screen name

What it is

HarmonyOS, and the cross-end frameworks that target WeChat, Alipay, and several mini-program hosts, treat “write once, ship to phone, foldable, tablet, car, television, watch” as the default way to ship. Layout cannot be chosen by the marketing name of a screen—“phone layout,” “tablet layout,” “car page” all fail when a foldable is half open, a car screen is a wide short strip, or a tablet has a keyboard attached. Choose layout by capability: current width, whether a pointer exists, whether a physical keyboard exists, whether the surface is glanceable, whether speech must lead, whether two panes can show at once.

This is how the layout axis is named when one codebase ships to many ends, not how a live task continues onto another device. Continuation migrates a session; here the same code grows a different UI under a different combination of capabilities.

Why it happens

Device names are retail categories. Capabilities are what layout actually reads. An unfolded foldable can be wider than many tablets; a car screen is a very wide, very short band; a watch has almost no width and is often always-on. A selector written as device == phone hands every one of those surfaces the wrong layout. Width, aspect, pointer precision, keyboard presence, and “can two panes sit side by side” are orthogonal axes: at the same width, a mouse and a finger-only input imply different density and different hover availability.

Write-once works when the UI responds to those axes, not when it is N pages named after devices. Capabilities also change at runtime: folding, attaching a keyboard, split view, and casting to the car are flips inside one process. A cached “this is a tablet, so two columns” keeps the old column count after the capability has already changed. Television adds a far-distance, d-pad-or-remote capability; a touch-density list cannot simply be scaled up and thrown at the wall.

Where it stops holding

An app that has one surface, never casts, and never folds pays little for a single hard-coded width; the capability axis barely earns its keep. Games and camera finders bound to sensors often choose on “is this sensor present,” not on width breakpoints. A mini-program host may not expose the full capability set (no car hardware keys, no desktop multi-window); a finer selector will still be clipped by the host. A brand marketing page that is deliberately a fixed canvas degrades to a scrollbar on other ends—admit it is not capability-responsive, rather than pretending it has breakpoints.

Applying it

• Select on width, pointer type, keyboard, pane count, glance versus far-distance. Do not use “phone,” “iPad,” or “car” as conditions in layout code or in mock filenames.
• Treat folding, split view, and an attached keyboard as runtime capability changes: column count and master-detail structure follow the current capabilities, and are not locked at launch.
• Declare a minimum capability for watch and car (glance, d-pad, speech). Below the threshold, offer a reduced task rather than shrinking the phone page.
• Verify by opening the same task from one build on a narrow phone, an unfolded foldable, a wide-short car simulator, and a watch, and recording which structure each end used. Two ends with similar width that diverge only because of filenames, or a fold that does not change column count, mean the selector still reads a device name. Then attach a keyboard and confirm pointer-related hover and density follow immediately.

Related

• Same group: R4.04.1 Distributed continuation across devices · R4.04.2 Constraints of mini-programs inside super-apps · R4.04.3 Points of divergence from international platform conventions · R4.04.5 Service cards surface functions at the desktop layer · R4.04.6 System-owned identity and payment change flow boundaries
• Adjacent: R3.11 Responsive implementation and breakpoint strategy · K1.02 Screen size and density
• Search terms: capability-based layout · multi-end deployment · foldable · breakpoint