Das Aerona App-Format

Wie eine .aero-Datei aufgebaut ist

Im Kern ist es ein JSON-Dokument – reiner Text, den man mit jedem Editor öffnen und lesen kann. Es sagt dem System, wie die App heißt, wie sie aussieht und was sie anzeigt. Beim Öffnen läuft sie abgeschottet in einer eigenen Kapsel – ohne Zugriff auf das Betriebssystem oder andere Apps. Dass die Datei lesbar bleibt, ist Absicht: Deshalb stecken sogar Bilder als Text darin und nicht in einem gepackten Behälter (mehr dazu unter „Was noch kommt“).

{
  "format": "aerona-app",
  "formatVersion": 1,
  "id": "com.aerona.willkommen",
  "name": "Aerona Willkommen",
  "version": "1.0.0",
  "author": "Aerona",
  "accent": "#3b82f6",
  "permissions": [],
  "entry": {
    "type": "html",
    "html": "<h1>Hallo Aerona!</h1>"
  }
}

Gekürzt: Die echte Datei trägt dazu eine Beschreibung, ein Symbol als SVG in einer einzigen Zeile, im Feld html eine ganze Seite – und in der signierten Fassung am Ende das Feld signature.

Das Beispiel ist ein Paket nach Version 1: Die ganze Seite steckt in einem einzigen Feld. Ein Paket nach Version 2 bringt mehrere Dateien mit und nennt die, mit der es startet. Jede Datei steht als Text im Manifest, die Datei bleibt also lesbar.

"entry": {
  "type": "html",
  "main": "index.html",
  "files": {
    "index.html": "<!doctype html>…",
    "app.js": "…",
    "style.css": "…"
  }
}

Pflichtfelder

Optional

Wie Apps abgesichert sind

Das Häkchen „Verifiziert“

Was schon geht

Vier Dinge standen hier lange unter „kommt noch“. Seit dem 25.07.2026 sind sie im AetherOS-Code gebaut:

Was eine App darf

Eine App sitzt in ihrer Kapsel und kommt an nichts heran. Jedes Recht öffnet genau eine Tür. Die Rechte einer App stehen sichtbar auf ihrer Karte, man sieht sie also vor dem Start.

Die Absicherung, genauer

Die vier Punkte oben in der ausführlichen Fassung. Das Sicherheitsmodell hat acht:

Der Weg einer App, Schritt für Schritt

Vom Einfügen der Datei bis zur laufenden App prüft das System an sechs Stellen. Jede Stelle steht in einer eigenen Datei des AetherOS-Codes.

1. Einlesen und prüfen. Das Manifest muss stimmen: Format „aerona-app“, Version 1 oder 2, eine Kennung wie com.aerona.notiz, ein Name bis 60 Zeichen, eine Versionsnummer X.Y.Z, und es darf nicht zu groß sein.
2. Signatur nachrechnen. Hat die Datei eine Signatur, rechnet das Installations-Tor sie nach und hält das Ergebnis fest. Ist „Nur signierte Apps“ an, endet hier alles Unsignierte.
3. Ablegen. Die App kommt in den Speicher des Systems unter aerona_installed_apps. Entfernen löscht sie dort samt ihren Daten.
4. Vor dem Start noch einmal prüfen. Der Speicher könnte seit der Installation verändert worden sein – deshalb wird das Manifest erneut geprüft, und bei eingeschaltetem Tor auch die Signatur.
5. Kapsel bauen. Die App bekommt ein Fenster von 720 × 520, ein Spiel 960 × 600. Darin läuft sie in einem Rahmen, der nur Skripte erlaubt, ohne eigene Herkunft. Als Erstes steht dort eine Inhaltsregel, die alles verbietet, was nicht ausdrücklich erlaubt ist.
6. Über die Brücke fragen. Was die App vom System will, fragt sie über window.aerona an. Jede Anfrage wird gegen ihre Rechteliste geprüft.

Die Grenzen in Zahlen

So steht es im Code, der die Dateien prüft. Was darüber liegt, lehnt das System ab – mit einer Meldung, die das Feld beim Namen nennt, statt die App still abzuschneiden. Zum Vergleich: Die größte App im Format, Horizon Audio, braucht mit 142.674 Bytes nicht einmal ein Zehntel dessen, was ein Paket nach Version 2 darf.

Wie eine App signiert wird

Wer .aero liest und schreibt

Fünf Beispiele, und was jedes zeigt

Zum Format gehören fünf kleine Beispiel-Apps. Sie sind Proben für das Format, keine fertigen Programme.

Eine echte App gibt es auch schon: die Klangabstimmung Horizon Audio, als .aero gepackt.

Größen der unsignierten Fassungen, ausgelesen am 23. September 2026. Horizon Audio ist das einzige Paket nach Version 2.

Was noch kommt

Das Format wächst weiter. Noch nicht gebaut sind drei Dinge – bei jedem steht, warum es noch wartet: