Native Rendering

Hypen does not ship a WebView. On every platform, the adapter translates the engine's patch stream into that platform's own UI primitives:

A Button in your template becomes an actual <button> on the web, an actual Compose Button on Android, and an actual SwiftUI Button on iOS.

The Patch Model

The engine never hands a renderer a finished screen. It emits a minimal set of tree edits:

Create      — make a node of some type
SetProp     — set a property on a node
RemoveProp  — clear a property
Insert      — attach a node to a parent at an index
Move        — reorder a node
Remove      — detach a node

Renderers apply these to a live tree they own. That has three consequences:

Updates are minimal. Changing one counter sends one SetProp, not a new screen. Over a remote connection that is a handful of bytes.

Renderers stay simple. An adapter implements six operations plus a paint pass — not a layout engine, a diffing algorithm, or a scripting runtime. That's why the surface is small enough to port.

Platform state survives. Because nodes persist across updates rather than being re-created, scroll position, text selection, focus, and in-flight animations aren't destroyed by a state change.

What You Inherit

Rendering to native components means you get the platform's own behaviour for free, rather than reimplementing it:

• Text input — the real IME, the real autocorrect, the real keyboard. The desktop renderer wires winit's Ime events through to an inline preedit; mobile adapters use the system editor.
• Scrolling — native momentum, rubber-banding, and trackpad semantics.
• Accessibility — the platform's own tree. VoiceOver, NVDA, and Orca see real widgets (desktop goes through AccessKit); Compose and SwiftUI expose their native semantics. See Accessibility.
• Selection and clipboard — system copy/paste, with native modifiers.
• Look and feel — native focus rings, cursors, and press states.

Performance

There is no JavaScript bridge and no DOM emulation on native platforms. The desktop renderer rasterises on the GPU through Vello, shapes text with cosmic-text, and lays out with Taffy — all in-process, all in Rust. Patches arrive, the damaged region repaints, and that's the whole frame.

On the web, DOM mode writes directly to elements. Canvas mode is available when you want pixel-identical output across browsers instead of native DOM semantics — the same template, a different trade-off.

Consistency vs. Nativeness

Rendering natively means platforms differ where platforms genuinely differ — a SwiftUI button and a Compose button do not look identical, by design. Hypen gives you shared structure and behaviour, not pixel-identical output. Where you need pixel identity, Canvas mode on web and the desktop renderer's own rasteriser give you it.

Component coverage per platform is tracked in the component gallery, which is regenerated as adapters change.

See Also

• Platforms Overview — every adapter
• Multi-Platform — what's shared, what isn't
• Remote UI — the same patches, over a network
• Component Gallery — per-platform component parity