AURA 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 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 and aura-demo demonstrate the compiled path.
- The playground loads editable
.aurafiles through the dynamic loader. - The current port uses browser threads. HTTPS and cross-origin isolation with COOP/COEP are required; the browser guide explains building and hosting.
- Native child processes, SCSI/hotplug, application HTTP/TLS servers, the remote HTTP server and CEF WebView are unavailable.
aura-netcurrently 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 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 for details of the libraries used.
CMake platform configuration · tools/web · native core · Download Markdown