Die App Engine
Titelleiste, Seitenleiste, Einstellungen, Mitteilungen, Stile und Übersetzungen gibt es einmal – jede App bindet sie ein. Das ist die App Engine: die Plattform unter allen zehn Apps. Der Grund dahinter ist schlicht: Was in elf Ordnern als Abschrift liegt, läuft auseinander, und jede Reparatur müsste elfmal gemacht werden. Hier steht, was die Engine jeder App mitgibt, wie eine App aus ihr entsteht und was daran noch nicht rund ist.
Auf einen Blick
Apps
Vorlage: Rohbau
Hooks im Kern
Reiter im Studio
Bereiche des Servers
Was die Engine jeder App gibt
Bedienung
- Titelleiste und Seitenleiste (mit Schnellaktionen, „Läuft gerade“ und Ziehen und Ablegen) – in jeder App an derselben Stelle, damit man sich nach dem Wechsel nicht neu zurechtfinden muss
- Befehlspalette – mit Strg+K in jeder App, wie auf Was man einstellen kann beschrieben
- Mitteilungen – eine Zentrale mit Filtern und Suche, im Bild weiter unten
- Zen-Modus – in den Einstellungen steht er als „Auto-Fokus (Zen-Modus)“
Daten
- Speicher, Zwischenspeicher, Dateisystem – jede App legt ihre Daten auf dem Gerät ab, nicht in einer Cloud
- Datenschema und Transaktionen – also mehrere Änderungen, die nur zusammen gelten
- eine eigene kleine Datenbank, die jede App über denselben Baustein anspricht; die Einstellungen haben dafür eine „Datenbank-Diagnose“
Funktionen
- Übersetzungen – die Sprachdateien liegen einmal in der Engine, jede App liest dieselben
- automatisches Speichern und ein Verlauf der Änderungen
- Suche – in Aerona Settings etwa mit Strg+F über alle Einstellungen
- Barrierefreiheit – hoher Kontrast, sichtbarer Tastatur-Fokus und weniger Bewegung stehen in jeder App unter Allgemein → Einstellungen
System und Oberfläche
- Absturzbehandlung, Klang, Abgleich, Tastenbelegung – was bei einem Absturz passiert, ist in jeder App dasselbe
- Themen, Fenster, Mauszeiger, Hinweise
- Stile und Design-Werte an einer Stelle: Schrift und Farben kommen aus gemeinsamen Werten, nicht aus Angaben am einzelnen Element; die 13 Stile stehen auf Alle 13 Stile
Erweiterbar
Ein Erweiterungssystem und zwei Verzeichnisse – eines für Befehle, eines für Bausteine – lassen neue Teile andocken, ohne den Kern zu ändern. Das ist wichtig, weil der Kern in allen Apps gilt: Eine Änderung dort trifft alle zehn auf einmal. Die 21 Erweiterungen, die tatsächlich geladen werden, liegen in der Engine selbst. Zwei alte Ordner in jeder App – Abschriften von Erweiterungen und ältere Oberflächen-Dateien – wurden am 1. August 2026 gelöscht, erst nachdem auf vier Wegen bewiesen war, dass sie niemand mehr lädt.
Der Kern in Zahlen
Nachgezählt am 23. September 2026 in 00_Engine_Core, dem gemeinsamen Kern, und am 27. September noch einmal – alle Zahlen sind gleich geblieben. Die Apps holen den Kern über den Kurznamen @engine, deshalb muss keine App wissen, wo er auf dem Rechner liegt. Ein Hook ist ein wiederverwendbares Stück Verhalten, ein Manager kümmert sich um genau eine Aufgabe, etwa den Speicher oder die Fenster. Gezählt ist jede Datei einmal; eine Sicherungskopie zählt nicht mit.
Die Bausteine im Bild
Die Bilder stammen aus den Apps. In jeder steht oben dieselbe Titelleiste mit dem Namen der App und der Uhrzeit, links die Seitenleiste. Dass es vier verschiedene Apps sind, sieht man am Inhalt, nicht am Rahmen – genau das ist die Aufgabe der Engine. Die Bilder stammen vom 15. September 2026; seit dem 25. September trägt der Aerona-Stil der Apps die Gestalt des Einstellungsfensters dieser Webseite, mit Zeilen statt Kästen und dem Verlauf in Schaltern und Symbolen.
Wie eine App entsteht
Aus der Vorlage
Jede App beginnt als Rohbau – der Vorlage, aus der alle Aerona-Apps entstehen. Werkzeuge übertragen den Kern in die Vorlage und von dort in alle Apps. Der Rohbau ist selbst eine lauffähige App mit eigener Seite; was dort funktioniert, soll in jeder neuen App von Anfang an funktionieren.
Entwickeln
Beim Bauen läuft die App im Entwicklungsserver Vite, zusammen mit einem Electron-Fenster. Am 25. September 2026 stand das Fenster des Rohbaus erst nach 5,8 Sekunden: Der Server übersetzte über 700 Dateien der Einstellungen im Voraus, gleichzeitig mit dem Start, und die Startdatei warf jedes Mal seinen Zwischenspeicher weg. Seitdem wartet das Vorübersetzen, bis die App offen ist, und das Fenster steht nach 1,3 Sekunden – nachzulesen im Bautagebuch.
Für Windows
Ein Bauschritt packt die App als Windows-Installer, sodass sie sich wie jedes andere Programm einrichten lässt. Erschienen ist noch keine App – der Start ist für Sommer 2027 geplant.
Für Mac, Linux und das Handy
Bauschritte dafür gibt es in jeder App. Für Mac und Linux wurde damit noch nichts gebaut. Für das Handy steckt die App in einer Capacitor-Hülle; ein iOS-Projekt liegt bisher nur im Kern, in keinem der App-Ordner.
Eine neue App in vier Schritten
So arbeitet BUILD_NEW_APP.bat im Hauptordner der Engine. Es fragt zuerst nach dem Namen des neuen Ordners, etwa „app_011_…“, und warnt, wenn es ihn schon gibt. Danach laufen vier Schritte ab, die es selbst von 1 bis 4 durchzählt:
- Filter anlegen. Bauordner, fremde Pakete und die Versionsverwaltung bleiben beim Kopieren draußen. Sonst würde die neue App die Bauergebnisse der alten mitschleppen.
- Kopieren. Eine vorhandene App wird als Ganzes in einen neuen Ordner kopiert. Die Weiterleitungen in die Engine kommen dabei mit, die neue App teilt sich den Kern also von Anfang an.
- Umbenennen. In der
package.jsonwird nur der Name ersetzt. Alles andere darin – Version, Befehle, Bausteine – bleibt, wie es in der Vorlage stand. - Einrichten. Die Pakete werden installiert, und eine Startdatei entsteht. Installiert wird einmal für den ganzen Bereich, nicht je App, so verlangt es Regel 12.
Drei Dinge sind hier noch nicht rund: Das Werkzeug kopiert heute Aerona Settings, nicht den Rohbau, den die Anleitung als Vorlage nennt. Port, Kennung und Produktname der neuen App bleiben die alten – sie müssen von Hand angepasst werden. Und den Namen schreibt es mit einem Befehl der Windows-Kommandozeile um, der Umlaute beschädigen kann; im übrigen Aerona gilt deshalb die Regel, Texte nur mit einem Werkzeug zu ändern, das Umlaute nachprüft. Nachgezählt am 27. September 2026 gibt es elf App-Ordner: die zehn Apps und den Rohbau.
Befehle in jeder App
App-Ordner: zehn Apps und der Rohbau
Befehle in der package.json jedes Ordners
Versionsnummer in allen elf Ordnern
Vorher prüfen
„doctor“ sucht Node.js, npm und Git und die Werkzeuge für Handy-Fassungen. Die Werkzeuge für iOS prüft er nur auf einem Mac. So erfährt man vor dem Bauen, was fehlt, und nicht erst an einer Fehlermeldung mitten im Lauf. Das Skript liegt einmal in den Entwicklerwerkzeugen der Engine, alle elf Ordner rufen dasselbe auf.
Aufräumen
„clean“ löscht Bauordner wie dist und dist-react und die Zwischenspeicher von Vite. Das ist der Weg, wenn ein Bau alte Teile zeigt, die es in der Quelle nicht mehr gibt. Die Quelle selbst fasst er nicht an.
Prüfreihen
„test“ startet Vitest, „test:ui“ dasselbe mit einer Oberfläche. Seit dem 1. August 2026 laufen die Prüfreihen vor jedem Eintrag in die Versionsverwaltung von selbst, dazu unten mehr. Eine Prüfreihe fängt ab, was ein grüner Bau nicht meldet.
Handy
Ein Befehl öffnet das iOS-Projekt in Xcode. Ein iOS-Projekt liegt bisher aber nur im Kern, in keinem der App-Ordner. Für die übrigen Handys gibt es einen Befehl, der die Oberfläche baut, in die Handy-Hülle überträgt und eine Probefassung zum Installieren erzeugt – eine Fassung für einen App-Laden ist das noch nicht.
Eine Quelle statt Kopien
Seit dem 1. August 2026 liegen viele Dateien nur noch in der Engine, vor allem die der Einstellungsseite. In den Apps steht an ihrer Stelle eine kurze Weiterleitung dorthin. Am 16. September 2026 waren es 5.616 solcher Dateien in den elf App-Ordnern, und am 27. September sind es genauso viele. Vorher trug jede App ihre eigene Abschrift, und die liefen längst auseinander: Eine Datei der Sprachauswahl hatte im Rohbau 168 Zeilen, in den anderen zehn Apps 161. Der mehrfach vorhandene Quelltext schrumpfte an diesem Tag von 14.442 auf 687 KB.
Daneben gibt es fünf Werkzeuge. Sie tragen Änderungen aus dem Kern in die Apps; vier davon überspringen dabei jede Weiterleitung. Der Grund: Ein Kopierbefehl würde eine Weiterleitung durch eine echte Abschrift ersetzen, die App liefe weiter, alles wäre grün – und die Datei liefe von da an wieder auseinander. Ein gemeinsamer Schutz in weiterleitung.js stoppt deshalb jeden Versuch, auf eine Weiterleitung zu schreiben.
„Sie vergleichen nicht, sie fragen nicht, sie sichern nicht.“
LIESMICH der Werkzeuge, 07_Aerona_App_Engine/_werkzeuge
Vor jedem Lauf
- Nachsehen. Im Git-Stand prüfen, ob eine der Zieldateien eigene Änderungen einer App trägt. Die Werkzeuge kopieren eine feste Liste von Dateien; eine Anpassung, die nur in einer App steckt, wäre danach lautlos weg.
- Sichern. Vorher committen – das ist hier der einzige Weg zurück. Die Werkzeuge legen selbst keine Sicherung an.
- Starten, nicht nur bauen. Ein Bauvorgang meldet nicht, wenn eine Anpassung verloren gegangen ist. Am 29. Juli 2026 lief ein Bau fehlerfrei durch, obwohl zwei Bausteine der Rechner-App stillgelegt waren; aufgefallen ist es nur, weil zwei Teile im Bauergebnis fehlten.
Die Reihenfolge zählt: erst vom Kern in die Vorlage Rohbau, dann von der Vorlage in die übrigen Apps. Sonst trägt der zweite Lauf den alten Stand weiter. Nachlesen lässt sich das alles im Regelwerk, Regel 12 „App Engine und React“, auf Das ganze Regelwerk.
Die Technik
| Baustein | wofür | Version in den Apps |
|---|---|---|
| React | die Oberfläche – die App Engine ist der einzige React-Bereich von Aerona | 19 |
| Vite | bauen und entwickeln | 7 |
| Electron | das Fenster auf dem Rechner | 43 |
| Capacitor | die Hülle für das Handy | 8 |
| Vitest | Prüfreihen | 4 |
Aus den package.json der Apps, am 27. September 2026 in allen elf Ordnern gleich. Die Regel dazu: Fremdpakete wie React oder Electron sind in Ordnung – mit Bedacht gewählt. React ist dabei eine dokumentierte Ausnahme: Webseite und AetherOS kommen ohne aus, nur die App Engine nutzt es. Die package.json des Kerns selbst nennt noch Electron 28 und die Version 2.0.0; die Apps sind am 1. August 2026 auf Electron 43 umgezogen, der Kern hat diesen Umzug in seiner eigenen Angabe noch nicht mitgemacht.
Regeln nur für die Engine
300 Zeilen
Auch hier gilt die Grenze von 300 Zeilen je Datei, „erbarmungslos“, wie Regel 12 sagt. Wer mehr als drei Zustände in einem Baustein braucht, lagert die Logik in einen eigenen Hook aus. Ganz eingehalten ist das noch nicht: Zu lange Dateien kürzen steht unten bei dem, was offen ist.
Ordnung im Code
Werte werden höchstens über drei Ebenen durchgereicht, sonst über einen gemeinsamen Zusammenhang. Jeder Effekt räumt hinter sich auf – wer einen Zeitgeber oder Lauscher anlegt, entfernt ihn auch wieder. Sonst wächst der Speicherverbrauch, je länger eine App offen ist.
Keine festen Schriftangaben
Schrift und Farben kommen aus gemeinsamen Design-Werten, nicht aus Angaben am einzelnen Element. Nur so kann ein Regler für die Schriftgröße die ganze App auf einmal verändern, ohne dass sie neu lädt. Die Regeln stehen vollständig in Regel 12 auf Das ganze Regelwerk.
Das Studio
Neun Reiter
- Assets
- Brain
- Data
- Design
- Edit
- Lab
- Layout
- Market
- Media
Werkzeuge darin
- Gerätesimulator
- Bauablauf mit Vorschau
- Code-Editor
- Zusammenarbeit
- Layout-Editor mit Rückgängig
- Projektverwaltung und App-Suche
Bearbeiten ohne Code
Die Alt-Taste schaltet den Textbearbeitungsmodus um; mit Strg öffnet sich der Layout-Editor, der Elemente verschiebt. So lässt sich ein Wort oder eine Lage direkt an der laufenden App ändern, statt die Stelle erst im Quelltext zu suchen.
Im Textmodus zeigt ein grüner Rahmen, dass man Texte umschreiben kann; verschieben lässt sich darin nichts. Beide Modi sind für die Entwicklung gedacht: In der fertig gebauten App wirken die Tasten nicht, außer man schaltet die Textbearbeitung bewusst frei. Wer eine fertige App benutzt, verändert sie also nicht aus Versehen mit einem Tastendruck.
Der Server
Bereiche
- Gesundheit, Projekte, Anmeldung
- Dateien, Veröffentlichen, Git
- Fehler, Übersicht
- Marktplatz, Erweiterungen, KI
- Apps
Für die Apps
Der Bereich „Apps“ nimmt Absturzberichte und Statistik-Ereignisse an und liefert Einstellungen aus der Ferne. Weil der Server nur auf dem eigenen Rechner läuft, landen diese Berichte heute auch nur dort. Ein Dienst, an den fertige Apps einmal etwas schicken, ist das noch nicht.
Ehrlich
Der Server gehört zum Studio. Eine Anbindung an einen fremden KI-Dienst im Netz gab es bis zum 4. Oktober 2026; sie passte nicht zu Aerona und liegt seither im Archiv. Übrig sind eine KI auf dem eigenen Rechner (Ollama) und eine Attrappe für Proben.
Nur auf dem eigenen Rechner
Er lauscht ausschließlich auf der Adresse 127.0.0.1, Port 3001 – von einem anderen Gerät aus ist er nicht zu erreichen. Das steht so in seiner Startdatei und lässt sich dort nachlesen. Seine Ordner für Marktplatz, Erweiterungen und Projekte sind leer; die zwölf Bereiche sind also gebaut, aber noch ohne Inhalt, den jemand benutzt.
Wie der Server sich schützt
Anmeldung
Passwörter speichert der Server nur als bcrypt-Hash. Wer angemeldet ist, weist sich mit einem JSON Web Token aus. Ein Hash lässt sich nicht zurückrechnen: Selbst wer die Datenbank in die Hand bekäme, fände darin keine Passwörter. Wo dieser Schlüssel in den Apps liegt, ist noch nicht gut gelöst – er soll raus aus dem Browser-Speicher, das steht unten bei dem, was offen ist.
Bremsen
Je IP-Adresse gelten Grenzen: zehn Versuche zum Anmelden oder Registrieren in 15 Minuten, 20-mal Hochladen in zehn Minuten, 100 Git-Anfragen in 15 Minuten und 300 Anfragen in fünf Minuten. Die engste Grenze liegt bei der Anmeldung, weil dort jemand Passwörter durchprobieren könnte. Wer normal arbeitet, stößt an keine davon.
Gemeinsam arbeiten
Ein WebSocket-Server gibt jedem Projekt einen eigenen Raum. Mit Redis lässt er sich auf mehrere Server verteilen. Wer im selben Projekt arbeitet, sieht so die Änderungen der anderen; wer in einem anderen Projekt sitzt, sieht nichts davon.
Betrieb
Dateien für Docker Compose und Kubernetes liegen bei, dazu nginx als Lastverteiler. Für Anmeldung, Absturzberichte und Statistik nutzt er Prisma mit einer SQLite-Datenbank. SQLite ist eine einzelne Datei auf dem Rechner, kein eigener Datenbankdienst. Die Dateien für den Betrieb auf vielen Servern liegen bereit – solange der Server nur auf 127.0.0.1 lauscht, erreicht ihn aber ohnehin kein zweites Gerät.
KI-Hilfe
Ohne eigene Einstellung antwortet nur eine Attrappe, keine echte KI. Neben dem fremden Dienst kennt der Server Ollama, das auf dem eigenen Rechner läuft. Das ist der Weg, der zu Aerona passt: Nichts verlässt das Gerät. Den gleichen Gedanken verfolgt Aerona Lumina, der Übersetzer mit lokaler KI.
Ein Tag, an dem viel kleiner wurde
Am 1. August 2026 ging es in allen Apps um Kilobyte und Wartezeit. Den größten Sprung brachte dabei keine Kilobyte-Arbeit, sondern eine einzige Zahl: Das Startbild wartete fest 1,5 Sekunden, obwohl die App nach einer Zehntelsekunde fertig war. Jetzt wartet es nur so lange, wie es wirklich dauert, mindestens 400 Millisekunden, damit es nicht bloß aufblitzt. Vorher und nachher, aus dem Bautagebuch:
| gemessen | vorher | nachher |
|---|---|---|
| bis das Fenster steht | 1.200 ms | 300 ms |
| Startpaket einer App | 1.629 KB | 765 KB |
| Einstellungen, geöffnet auf dem Sprachreiter | 529 KB in einem Stück | 96 KB |
| Electron | 28, vom Dezember 2023 | 43 |
Sechs Apps, die nicht starten konnten
Am selben Tag fiel auf: Bei sechs Apps kam der Hauptprozess gar nicht hoch – monatelang unbemerkt, denn das Bauwerkzeug fasst den Hauptprozess nicht an. Ein grüner Bau war dort kein Beweis. Seitdem gilt in der ganzen Engine: Eine App gilt erst als fertig, wenn sie gestartet wurde, nicht schon, wenn sie gebaut ist.
Seitdem: Prüfen vor jedem Eintrag
Vor jedem Eintrag in die Versionsverwaltung laufen die Prüfreihen der App und eine Probe, ob die Beschleunigungen noch wirken – je etwa fünf Sekunden. Ist der Hauptprozess betroffen, kommen alle seine Dateien dazu, gut 70 Sekunden. Wie weit das trägt, zeigte sich am 25. September 2026: Beim Umbau auf den neuen Aerona-Stil schlägt eine Prüfreihe an, sobald die Webseite einen Pixel-Baustein verbessert und die App ihn noch nicht hat.
Was noch offen ist
Aus der Ideensammlung
- der Darkroom-Filter: nachts ein Blaulicht- und Schwarzweiß-Filter über allen Apps. Er gilt als günstigste Idee, weil er nur ein Überzug ist und kein neues System braucht. Dass überhaupt keine App-Idee umgesetzt sei, stimmt seit dem 16. September 2026 nicht mehr – im Rechner und in Aerona Audio sind etliche gebaut.
- der Anmelde-Schlüssel raus aus dem Browser-Speicher. Das Regelwerk sagt es deutlich: Dieser Speicher ist für Einstellungen da, nicht für Schlüssel.
- die Befehlspalette ausbauen: Heute kann sie suchen, später soll sie Befehle wie „Wecker um 8“ verstehen, egal welche App offen ist.
- ein Ereignisbus, damit Apps miteinander reden – etwa eine Sprachnotiz, die als Tagebucheintrag weiterwandert, ohne dass beide Apps voneinander wissen müssen.
- AeroSearch: eine Suche über alle Apps, die Termine, Notizen und Einstellungen an einem Ort findet. Sie braucht den Ereignisbus oder einen gemeinsamen Index, deshalb steht sie dahinter.
- doppelte Dateien zusammenführen und zu lange Dateien kürzen. Die maschinell zerlegbaren sind erledigt; der Rest ist Handarbeit.
- Apps als .aero-Pakete ausliefern. Das Format ist beschrieben (Das .aero-Format); eine App wirklich daraus zu laden, wäre der Beweis, dass die Beschreibung trägt.
Weiter
Alle Apps
Die zehn Apps und was sie können – jede mit eigener Seite und Bildern aus der echten App.
Was man einstellen kann
Die Einstellungswelt jeder App: die gemeinsame Einstellungsseite und die 13 Bereiche des Design-Editors.
Das .aero-Format
Das eigene App-Format, in dem die Apps einmal ausgeliefert werden sollen.
Entwicklungsbericht
Die Geschichte der App Engine, Eintrag für Eintrag mit Datum.
