# 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.

> **Typ:** konzept
> **Für wen:** Entwickler, die den Aufbau einer App verstehen wollen, bevor sie Manifest, Widget oder Server-Teil lesen.
> **Voraussetzung:** keine; Kenntnisse in TypeScript helfen beim Lesen der Beispiele.

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.

![Lebensweg einer App: Manifest und Release beim Plattformbetrieb, Kanäle bis stable, Installation in der Organisation, Bündel-Abholung mit Prüfung und Widget im Renderer auf dem Gerät](/de/apps-sdk/bilder/f0280cd8-app-lifecycle.svg)

## 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](https://szenera.com/de/docs/apps).

## Weiterführendes

- [Das Manifest](/de/apps-sdk/manifest) — jedes Feld mit Pflicht, Format und Wirkung.
- [Signieren und der Weg in den Katalog](/de/apps-sdk/signing-and-catalog) — Bündel, Signatur, Kanäle.
- [Apps im Handbuch](https://szenera.com/de/docs/apps) — die Sicht der Organisation.