Platform Support
zero-native exposes one runtime model across desktop hosts, but native affordances land per platform and per web engine. Unsupported operations return explicit runtime errors instead of pretending that every host can do the same thing.
Desktop Hosts
| Area | macOS system WebView | macOS Chromium | Linux system WebView | Linux Chromium | Windows system WebView |
|---|---|---|---|---|---|
| Main WebView | Supported | Supported | Supported | Unsupported | Supported |
| Child WebViews | Supported | Supported | Supported | Unsupported | Supported |
| Native views | Supported | Unsupported | Supported | Unsupported | Supported |
| Native control commands | Supported | Unsupported | Supported | Unsupported | Supported |
| App menus | Supported | Unsupported | Supported | Unsupported | Supported |
| System tray | Supported | Supported | Unsupported | Unsupported | Supported |
| Keyboard shortcuts | Supported | Supported | Supported | Unsupported | Supported |
| Dialogs | Supported | Supported | Supported | Unsupported | Supported |
| Clipboard text | Supported | Supported | Supported | Unsupported | Supported |
| Clipboard rich data | Supported | Supported | Supported | Unsupported | Supported |
| Open URL / reveal path | Supported | Supported | Supported | Unsupported | Supported |
| Notifications | Supported | Supported | Supported | Unsupported | Supported |
| Recent documents | Supported | Supported | Supported | Unsupported | Supported |
| Credentials | Supported | Supported | Supported | Unsupported | Supported |
| File drops | Supported | Unsupported | Supported | Unsupported | Supported |
| App activation events | Supported | Supported | Supported | Unsupported | Supported |
Runtime Queries
Use Runtime.supports(...) when native code needs to branch on the current host:
if (runtime.supports(.native_views)) {
try runtime.createView(.{
.label = "sidebar",
.kind = .sidebar,
});
}JavaScript can query the same support model through the built-in bridge when js_window_api or an explicit builtin_bridge policy allows zero-native.platform.supports:
const hasTray = await window.zero.platform.supports("tray");Feature names match the Zig PlatformFeature enum and the TypeScript ZeroNativePlatformFeature union. JavaScript callers may use either snake_case names such as native_views or camelCase aliases such as nativeViews. Unsupported operations still reject explicitly if called; support checks are intended for choosing UI affordances before making those calls.
Native Surfaces
The macOS, Linux, and Windows system-WebView hosts support toolbar, titlebar_accessory, sidebar, statusbar, split, stack, button, icon_button, checkbox, toggle, segmented_control, text_field, search_field, label, spacer, and progress_indicator native view kinds.
ViewKind.webview is the compatibility path for WebView-backed views. Existing runtime.createWebView(...) and window.zero.webviews.* APIs remain available.
Chromium builds are currently enabled on macOS only. Linux and Windows Chromium host files are placeholders and build/package tooling rejects those targets until the native hosts are implemented.
Mobile And GPU
iOS and Android are supported today through embedded host examples rather than the desktop platform host matrix. The mobile examples own native header/navigation layout in UIKit or Android views, embed a WKWebView or Android WebView as the workspace, and drive zero-native through the C/JNI lifecycle, activation, resize, and command calls documented in Embedded App.
| Area | iOS embedded host | Android embedded host |
|---|---|---|
| Native header/navigation | UIKit header with Back and Refresh command buttons | Android view header with Back and Refresh command buttons |
| WebView content area | WKWebView workspace | Android WebView workspace |
| Runtime lifecycle | zero_native_app_create, start, activate, deactivate, stop, and destroy from Swift | JNI bridge for create, start, activate, deactivate, stop, and destroy |
| Resize and orientation | viewDidLayoutSubviews forwards WebView size and screen scale | Orientation/screen-size changes stay in the activity; surfaceChanged forwards size, density, and Surface |
| Keyboard avoidance | Keyboard frame notifications adjust the WebView bottom constraint | windowSoftInputMode="adjustResize" lets Android relayout the content area |
| Back/navigation command | Native Back button dispatches mobile.back | Native Back button and system Back dispatch mobile.back |
| Touch forwarding | UIKit/WebKit own touch handling for the WebView workspace | MotionEvent pointer data is forwarded through zero_native_app_touch |
Generic ShellView mapping | Mobile shell metadata feeds generated UIKit host config for header labels, command buttons, and WebView workspace | Mobile shell metadata feeds generated Android host config for header labels, command buttons, and WebView workspace |
Mobile hosts own safe areas, orientation, keyboard avoidance, back gestures, and platform lifecycle integration. The current mobile mapping is package-time shell metadata for native header/workspace structure; dynamic generic native view bridge commands should still be treated as desktop APIs until UIKit and Android runtime view mutation is added.
gpu_surface is reserved for future custom drawing regions. Current hosts report unsupported operations for that view kind and runtime.supports(.gpu_surfaces) / window.zero.platform.supports("gpuSurfaces") return false.