The second platform where UI splits
Build a native UI for one OS and the second platform starts a fork: its own components, its own spacing rules, its own set of layout bugs. Keeping two interfaces looking the same means maintaining two sources of truth that drift the moment someone edits one.
A mini-program runtime ships a component library that the host renders through one contract, so the same buttons, lists, and sheets look identical on every host you target.
What a shared component library is
The runtime exposes a fixed set of primitives — WeChat's WeUI and Alipay's Ant Design Mini are examples — that the host paints with native fidelity. Your layout describes intent (a card, a tab bar), not pixels, and the runtime resolves it on each platform. Material Design and the W3C design-tokens work describe the same idea for the open web.
Where the gap shows up
| Step | Native (per platform) | Mini-program runtime (shared library) |
|---|---|---|
| Components | Rebuilt per OS | One library |
| Layout rules | Diverge | Same contract |
| Visual bugs | Per platform | Shared, fixed once |
| Design system | Duplicated | Single source |
| New host | New fork | Reuse library |
The result is one interface that means the same thing wherever it appears.
Why shared beats forked
A shared library means a visual fix lands once and reaches every host, instead of being patched in three places and still disagreeing. It also means a new host inherits the existing design system rather than starting a third fork.
How Cross Mini App applies it
Cross Mini App runs programs on a runtime with a shared component contract, so your design system renders identically across hosts. You build the interface once; the runtime keeps it consistent. You stop maintaining three UIs and start owning one.
That is the difference between an interface that forks and an interface that holds.
