Was ist eine App, und wie kommt sie auf den Bildschirm?

Eine App ist eine fachliche Erweiterung der Plattform: ein Manifest, höchstens ein Widget und bei Bedarf ein Server-Teil. Diese Seite zeigt ihren Lebensweg vom Manifest bis zum Widget in der Szene — und sagt, was davon heute wem offensteht.

Eine App startet keinen eigenen Prozess. Sie ist ein Paket, das die Plattform lädt und das sich in vier Flächen zeigt: dem Manifest mit Identität, Widgets, Rechten, Datenzugriff und Signaturpolitik; einem optionalen Server-Teil mit Resolver, Fetcher und Jobs; dem runtime-Bündel, das der Player lädt; und dem authoring-Bündel mit dem Konfigurationsformular für den Szenen-Editor. Das Manifest ist die einzige verbindliche Beschreibung: Was dort nicht steht, gibt es für Katalog, Portal und Gerät nicht. Jede App trägt höchstens ein Widget — die App ist die Einheit, die eine Organisation installiert, bewertet und wieder entfernt; mehrere Darstellungen löst ein Widget über seine Vorschau-Varianten und ein Konfigurationsfeld.

Wie viel Maschinerie eine App trägt, ordnet sie in drei Stufen. Ein Teil der mitgelieferten Apps rendert allein aus seiner Konfiguration und hat keinen Server-Teil (clock, webpage, notice-board, countdown, countup, world-clock, word-clock, ticker, qr-code, youtube, stream, embed). weather, rss, tagesschau und calendar ziehen mit einem Fetcher aus fremden Quellen, die Marken-Apps bbc, bild, deutschlandfunk, ndr und spiegel erben Server-Teil und Widget von tagesschau. Eigene Ressourcen in einer eigenen App-Datenbank halten pharmacies-on-duty mit Fetcher und wiederkehrendem Job und menu-board ohne jeden Abruf nach außen. opening-hours kommt mit einem Server-Teil aus, der nur den Standort liest, ohne Fetcher, Ressourcen und Datenbank. Dazu kommen die Tor-Apps ohne Fläche, onedrive und video-wall: Sie bringen kein Widget mit, sondern schalten eine Funktion des Portals frei. Die vollständige Liste ist der Ordner apps/.

Auf den Bildschirm kommt eine App in vier Etappen. Der Plattformbetrieb legt aus Manifest und Bündel ein Release an; es friert Version, Manifest und Bündelverweis ein und startet im Kanal canary, von dem es Schritt für Schritt über beta nach stable hochgestuft wird. Eine Organisation installiert die App aus dem Katalog; die Installation kennt drei Zustände — aktiv, Update wartet (wenn eine neue Fassung in stable mehr Rechte, Datenzugriffe oder geänderte Bedingungen verlangt oder die installierte ausläuft) und deinstalliert. Das Gerät liest aus dem Szenen-Snapshot je App die eine Fassung, die das Display spielt: die installierte, denn Szenen derselben Hauptnummer folgen ihr. Hält eine Szene des Displays bewusst eine ältere Hauptnummer, spielt das Display diese Fassung für alle seine Szenen, und die Szene trägt dazu einen Hinweis, bis jemand sie hebt. Das fehlende Bündel holt das Gerät über GET /v1/apps/{appId}/{version}/bundle.zip und prüft den sha256-Wert und die Ed25519-Signatur, bevor es entpackt. Der Renderer prüft zuerst, ob die Fassung zu ihm passt: Das Manifest nennt in apiCompatibility.rendererHost den Host-Vertrag, den das Bündel braucht, und der Renderer lädt nur, was seine eigene Vertragsfassung abdeckt. Dann lädt er das runtime-Bündel und lässt es sein Widget registrieren. Ein Bündel, das nicht passt, lädt er gar nicht erst. Eines, das kein Widget mitbringt, ein fremdes registriert oder beim Laden scheitert, meldet er (widget.bundle.no-exports, …foreign-widget, …load-failed), statt die Szene zu reißen. Der Szenen-Editor lädt runtime- und authoring-Bündel auf demselben Weg aus der installierten Fassung und zeigt deren Widgets und Formulare.

Was daraus folgt#

• Releases legt der Plattformbetrieb an. Der Katalog kennt keine Einreichung und keine Prüf-Warteschlange; Anlegen, Hochstufen, Zurückstufen und Ausmustern sind Betreiberarbeit.
• Apps entstehen heute im Quellbaum der Plattform. Das SDK @szenera/apps-sdk ist ein Paket dieses Quellbaums und nicht auf npm veröffentlicht; es reist nicht mit dem Release-Zug der Dienste, sondern hat seinen eigenen Takt.
• Neue Fassungen bleiben verträglich. Felder einer Widget-Konfiguration kommen nur mit Vorgabe hinzu und verschwinden nie, denn eine Fassung muss die Konfigurationen ihrer Vorgängerinnen lesen. Der Server-Teil einer App läuft in genau einer Fassung und bedient jede, die ein Display noch spielt, deshalb ändern sich seine Routen, Ausgaben und Antworten nur additiv, und jede Route nimmt weiter an, was eine frühere Fassung schickt. Beides hält ein Test in jeder App gegen eine festgeschriebene Grundlinie.
• Einen Einreichungsweg für Apps Dritter gibt es nicht. Die folgenden Seiten beschreiben den Vertrag, gegen den die mitgelieferten Apps geschrieben sind — nicht ein Verfahren, das Sie heute durchlaufen könnten.
• Die Nutzersicht steht im Handbuch. Installieren, Rechte und Bedingungen aus Sicht der Organisation: Apps im Handbuch.

Weiterführendes#

• Das Manifest — jedes Feld mit Pflicht, Format und Wirkung.
• Signieren und der Weg in den Katalog — Bündel, Signatur, Kanäle.
• Apps im Handbuch — die Sicht der Organisation.