macOS, Linux, the browser

Platforms and backends

The same C++ runs on three targets through swappable backends: Cocoa and Metal on macOS, a headless null backend on a Linux server, and WebAssembly with WebGL2 in the browser. What runs where, and why the model is portable everywhere.

One codebase, three targets

The same C++ runs on the desktop, on a headless server, and in the browser. It does so by isolating everything platform-specific behind the Kinogaki Platform interfaces (ISystem, IWindow, the RHI) and swapping the implementation underneath. Pick a backend at build time; the libraries above never change.

                        Kinogaki UI  +  Kinogaki Core   (identical on every target)
                                    │
                        Kinogaki Platform interfaces
                          │            │            │
                    Cocoa/Metal    null/headless   WebAssembly/WebGL2
                      (macOS)        (server)         (browser)

The backends

Kinogaki Platform carries one implementation per target, plus the portable pieces shared by all:

cocoa (macOS). AppKit windowing and input, a Metal RHI. Objective-C++. This is the only full native windowing backend today, and the one kinogaki run uses.
null (headless). No window, no GPU. The server and a plain import kinogaki.platform load this. It exists so the model and the SDUI transport run on a Linux box with no display.
web (browser). Compiled to WebAssembly with Emscripten; draws through WebGL2. This is what kinogaki serve ships to a browser tab.
portable (events, the SDUI transport, the C ABI shim). No OS calls; compiled into every target.

What runs where

Capability	macOS	Linux	Browser (WASM)
The document model (Kinogaki Core)	yes	yes	yes
`kinogaki.platform` runtime + SDUI transport	yes	yes (null backend)	yes (web backend)
`kinogaki serve` (web app, browser UI)	yes	yes	it is the client
`kinogaki run` (a native OS window)	yes	no	no
GPU drawing	Metal	none (headless)	WebGL2

The model and serve are available everywhere. The native window (run) is macOS only, because a native window needs a native windowing backend, and only the Cocoa one exists. A Linux or Windows native window would mean writing an X11/Wayland or Win32 backend plus an RHI implementation for it: a real engineering project, not a recompile. Until then, the browser face is the cross-platform way to render the same view on any OS.

Why the model is portable everywhere

Kinogaki Core touches no operating system, so it compiles unchanged for macOS, Linux, and WebAssembly. The Python package proves it: the model and transport ship as plain C++ shared libraries (libkinogaki_core, libkinogaki_platform) built with the null backend, with no GPU or window dependency. That is why pip install kinogaki gives you the full model and serve on Linux and macOS alike (see building and shipping).

The render path is identical

Both real render targets, Metal on macOS and WebGL2 in the browser, draw through the same RHI and the same Canvas. The widgets do not know which backend is beneath them. A button is the same C++ on both; only the device that executes the draw calls differs. This is what makes the two faces match pixel for pixel, and why proving the board in the browser also proves it natively.

‹ The libraries The seams ›