# Target platforms

AURA has a native C++ runtime and a WebAssembly port. Interfaces, parsing, layouts and bindings share code; operating-system services depend on the target platform.

## Platform overview

| Target | Architecture | Status | Use |
|---|---|---|---|
| **Linux** | x86_64, ARM64 | Native reference platform; build packages available for both architectures | Desktop, touch terminals and kiosks |
| **Browser / WebAssembly** | Wasm through Emscripten | Existing port with Hello, demo and playground; limited system APIs | Interactive applications and UI previews in the browser |
| **Windows** | x64 in the configured Skia package | Graphics build paths prepared; the complete framework port is not approved for release | Potential native porting target |
| **macOS** | Intel x64, Apple Silicon ARM64 in the Skia packages | Graphics build paths prepared; the complete framework port is not approved for release | Potential native porting target |
| **iOS / iPadOS** | Browser / WebAssembly | Usable in the browser; the web runtime needs the required browser capabilities and hosting headers | iPhone and iPad without a separate native app |
| **Android** | Browser / WebAssembly | Web runtime in the browser; no dedicated native Android build path documented | Mobile browser applications |

“Prepared” refers to existing platform branches and dependencies, not a demonstrated complete build or a tested product release. A working example does not replace validation on a particular device.

## Linux: desktop and kiosk

Linux is the reference for native AURA development. The configured Skia packages are available for x86_64 and ARM64. C++20, CMake and Ninja form the build; [Getting started](getting-started.md) lists the Linux requirements.

SDL3 handles windows and input. Depending on the SDL build and target system, **X11**, **Wayland** or **KMS/DRM** can be available. KMS/DRM provides a direct display path for appropriately configured Linux kiosks; the graphics build accounts for EGL/GLES. Drivers, input devices, access permissions and the backends actually available remain part of device integration.

Device monitoring, SCSI media, hotplug/usbmuxd and native system information are platform-specific services. On Linux, system information uses `/proc` and `/sys` among other sources; these functions are not platform-independent browser APIs.

## Browser: the same UI runtime as Wasm

The browser port compiles the C++ scene graph, Skia, SDL3, language and bindings into WebAssembly through Emscripten. The UI is drawn in a canvas. AURA elements are not translated into HTML widgets.

- [Hello](../../web/hello.html) and [aura-demo](../../web/demo.html) demonstrate the compiled path.
- The [playground](../playground.html) loads editable `.aura` files through the dynamic loader.
- The current port uses browser threads. HTTPS and cross-origin isolation with COOP/COEP are required; the [browser guide](browser.md) explains building and hosting.
- Native child processes, SCSI/hotplug, application HTTP/TLS servers, the remote HTTP server and CEF WebView are unavailable. `aura-net` currently lacks a browser client adapter; HEIF is disabled in this build.

On iOS and iPadOS, AURA runs through its browser/WebAssembly port. A separate native App Store build is a different target. Keyboard, IME and device requirements depend on the browser and application. See the [browser chapter](browser.md) for further limitations and `SharedArrayBuffer` requirements.

## Windows and macOS: porting status

The Skia configuration contains download packages, library names and link settings for Windows x64 and macOS x64/ARM64. SDL3 is also integrated as a cross-platform window and input layer.

Other framework components still depend on Linux or POSIX. For example, native process code uses `spawn`, `poll`, `pipe2` and POSIX headers; device functions and CEF integration have additional platform assumptions. Complete support requires suitable implementations, an end-to-end build and tests on the respective platform. Windows and macOS are therefore listed as prepared porting targets.

## Modules and platform-specific limits

| Feature | Native Linux runtime | Current browser port |
|---|---|---|
| Widgets, text, layout, bindings, states, animation | Native C++ UI | Shared C++ code in Wasm |
| Compiled and dynamic `.aura` files | Both paths | Standalone examples and playground |
| JavaScript/Lua handlers | `AURA_WITH_SCRIPT` | Shared scripting runtime |
| Window-free PNG rendering | Native offscreen output for previews and tests | Does not replace the native headless workflow |
| HTTP(S), servers and remote control | Available according to build options | Native networking modules currently unavailable |
| HEIF/HEIC | Optional through libheif and decoder plugins | Disabled in this build |
| Chromium WebView | Optional; CEF build path for Linux | Unavailable |
| OS and device services | Linux/POSIX-dependent | Unavailable or specifically restricted |

## Headless and cross-builds

The native runtime can produce screenshots and galleries as PNG files without a window. This is useful for visual tests and previews and is a different workflow from browser canvas output.

For cross-builds, `aurac` must run on the build machine. `AURAC_EXECUTABLE` lets you specify a suitable host compiler for AURA files. A custom Skia package can be supplied through `AURA_SKIA_DIR`. The browser build uses a separate native host `aurac` and libraries built specifically for Wasm; native Skia archives cannot be used for that target.

## Sources and snapshot

This overview is based on `CMakeLists.txt`, `CMakePresets.json`, `cmake/SDL3.cmake`, `cmake/Skia.cmake`, `cmake/SkiaWasm.cmake`, `cmake/Cef.cmake`, the native core implementations and `tools/web/`. Snapshot: 1 November 2026. See [Dependencies & licenses](dependencies.md) for details of the libraries used.