# Zielplattformen

AURA hat eine native C++-Laufzeit und einen WebAssembly-Port. Oberfläche, Parser, Layouts und Bindungen teilen sich den Code; die Verfügbarkeit von Betriebssystemdiensten hängt von der Zielplattform ab.

## Plattformübersicht

| Ziel | Architektur | Stand | Einsatz |
|---|---|---|---|
| **Linux** | x86_64, ARM64 | Native Referenzplattform; Buildpakete für beide Architekturen vorhanden | Desktop, Touch-Terminal und Kiosk |
| **Browser / WebAssembly** | Wasm über Emscripten | Vorhandener Port mit Hello, Demo und Playground; eingeschränkte System-APIs | Interaktive Anwendungen und UI-Vorschau im Browser |
| **Windows** | x64 im vorkonfigurierten Skia-Paket | Grafik-Buildpfade vorbereitet; vollständiger Framework-Port nicht freigegeben | Mögliches natives Portierungsziel |
| **macOS** | Intel x64, Apple Silicon ARM64 im Skia-Paket | Grafik-Buildpfade vorbereitet; vollständiger Framework-Port nicht freigegeben | Mögliches natives Portierungsziel |
| **iOS / iPadOS** | Browser / WebAssembly | Im Browser nutzbar; die Web-Runtime benötigt passende Browserfunktionen und Hosting-Header | iPhone und iPad ohne separate native App |
| **Android** | Browser / WebAssembly | Web-Runtime im Browser; kein eigener nativer Android-Buildpfad dokumentiert | Mobile Browseranwendungen |

„Vorbereitet“ bezeichnet vorhandene Plattformzweige und Abhängigkeiten, nicht einen nachgewiesenen vollständigen Build oder eine getestete Produktfreigabe. Ein funktionierendes Beispiel ersetzt keine Prüfung auf dem konkreten Gerät.

## Linux: Desktop und Kiosk

Linux ist die Referenz für die native Entwicklung von AURA. Das vorkonfigurierte Skia-Paket gibt es für x86_64 und ARM64. C++20, CMake und Ninja bilden den Build; die [ersten Schritte](getting-started.md) nennen die Linux-Voraussetzungen.

SDL3 übernimmt Fenster und Eingabe. Je nach SDL-Build und Zielsystem stehen **X11**, **Wayland** oder **KMS/DRM** zur Verfügung. KMS/DRM ist der direkte Anzeigepfad für entsprechend eingerichtete Linux-Kiosksysteme; EGL/GLES werden im Grafik-Build berücksichtigt. Treiber, Eingabegeräte, Zugriffsrechte und tatsächlich verfügbare Backends bleiben Teil der Geräteintegration.

Gerätebeobachtung, SCSI-Medien, Hotplug/usbmuxd und native Systemdaten sind plattformnahe Dienste. Die Systemdaten verwenden unter Linux unter anderem `/proc` und `/sys`; diese Funktionen sind keine plattformunabhängigen Browser-APIs.

## Browser: die gleiche UI-Laufzeit als Wasm

Der Browser-Port baut den C++-Szenengraph, Skia, SDL3, die Sprache und Bindungen mit Emscripten zu WebAssembly. Die UI wird im Canvas gezeichnet. Es handelt sich nicht um eine Übersetzung der AURA-Elemente in HTML-Widgets.

- [Hello](../../web/hello.html) und [aura-demo](../../web/demo.html) zeigen den kompilierten Weg.
- Der [Playground](../playground.html) lädt bearbeitbare `.aura`-Dateien mit dem dynamischen Loader.
- Der aktuelle Port verwendet Browser-Threads. HTTPS und Cross-Origin-Isolation mit COOP/COEP sind erforderlich; der [Browser-Leitfaden](browser.md) beschreibt Build und Hosting.
- Native Kindprozesse, SCSI/Hotplug, eigene HTTP-/TLS-Server, der Remote-HTTP-Server und CEF-WebView stehen dort nicht zur Verfügung. Für `aura-net` fehlt derzeit ein Browser-Clientadapter; HEIF ist in diesem Build deaktiviert.

Auf iOS und iPadOS läuft AURA über den Browser-/WebAssembly-Port. Ein separater nativer App-Store-Build ist davon zu unterscheiden. Tastatur-, IME- und Geräteanforderungen hängen vom jeweiligen Browser und der Anwendung ab. Weitere Grenzen und die Voraussetzungen für `SharedArrayBuffer` stehen im [Browser-Kapitel](browser.md).

## Windows und macOS: Portierungsstand

Die Skia-Konfiguration enthält Downloadpakete, Bibliotheksnamen und Linkeinstellungen für Windows x64 sowie macOS x64/ARM64. SDL3 ist ebenfalls als plattformübergreifende Fenster- und Eingabeschicht eingebunden.

Andere Teile des Frameworks sind noch an Linux beziehungsweise POSIX gebunden. Beispielsweise verwendet der native Prozesscode `spawn`, `poll`, `pipe2` und POSIX-Header; Gerätefunktionen und der CEF-Integrationspfad haben weitere Plattformannahmen. Vor einer vollständigen Unterstützung sind passende Implementierungen, ein durchgängiger Build und Tests auf der jeweiligen Plattform nötig. Deshalb werden Windows und macOS hier als vorbereitete Portierungsziele geführt.

## Module und plattformabhängige Grenzen

| Funktion | Native Linux-Laufzeit | Aktueller Browser-Port |
|---|---|---|
| Widgets, Text, Layout, Bindungen, Zustände, Animation | Native C++-UI | Gemeinsamer C++-Code in Wasm |
| Kompilierte und dynamische `.aura`-Dateien | Beide Wege | Eigenständige Beispiele und Playground |
| JavaScript-/Lua-Handler | `AURA_WITH_SCRIPT` | Gemeinsame Skriptlaufzeit |
| PNG-Rendering ohne Fenster | Native Offscreen-Ausgabe für Vorschau und Tests | Kein Ersatz für den nativen Headless-Workflow |
| HTTP(S), Server und Fernsteuerung | Nach Buildoptionen verfügbar | Native Netzwerkmodule derzeit nicht verfügbar |
| HEIF/HEIC | Optional über libheif und Decoder-Plugins | In diesem Build deaktiviert |
| Chromium-WebView | Optional; CEF-Buildpfad für Linux | Nicht verfügbar |
| Betriebssystem- und Gerätedienste | Linux-/POSIX-abhängig | Nicht verfügbar oder gezielt eingeschränkt |

## Headless und Cross-Builds

Die native Laufzeit kann Screenshots und Galerien ohne Fenster als PNG erzeugen. Das ist für visuelle Tests und Vorschauen nützlich und bildet einen anderen Arbeitsablauf als die Canvas-Ausgabe im Browser.

Bei Cross-Builds muss `aurac` auf dem Build-Rechner laufen können. `AURAC_EXECUTABLE` erlaubt, einen passenden Host-Compiler für die AURA-Dateien vorzugeben. Ein eigenes Skia-Paket kann über `AURA_SKIA_DIR` eingebunden werden. Der Browser-Build verwendet einen separaten nativen Host-`aurac` und eigens für Wasm gebaute Bibliotheken; native Skia-Archive sind dafür nicht verwendbar.

## Quellen und Stand

Die Übersicht basiert auf `CMakeLists.txt`, `CMakePresets.json`, `cmake/SDL3.cmake`, `cmake/Skia.cmake`, `cmake/SkiaWasm.cmake`, `cmake/Cef.cmake`, den nativen Core-Implementierungen und `tools/web/`. Stand: 1. November 2026. Details zu den verwendeten Bibliotheken stehen unter [Dependencies & Lizenzen](dependencies.md).