# Eine eigene App entwickeln

Eine App bringt ein Manifest, ein Widget, ein Formular und optional einen eigenen Teil auf der Plattform mit. Sie entsteht aus einer Vorlage, und der ganze Weg bis zur Freigabe steht auf der Entwicklerseite unter `https://developer.szenera.com/apps/von-der-vorlage-bis-zur-freigabe`. Die Referenz mit Beispiel-Apps steht unter `https://developer.szenera.com/apps`, gegliedert nach Manifest, Widget und Vorschau, Datenzugriff und Signieren.

> **Typ:** nachschlagen
> **Für wen:** Teams, die eine eigene App für Szenera bauen wollen, statt eine vorhandene zu bedienen.
> **Voraussetzung:** Vertrautheit mit Web-Technik. Wer eine App nur einsetzen will, braucht diese Seite nicht.
> **Ort im Portal:** **Apps › Apps entdecken** — dort landet die fertige App.

## Was eine App im Manifest erklärt

Das Manifest ist die eine verbindliche Auskunft einer App über sich selbst. Was dort nicht steht, gibt es nicht: eine Darstellung ohne Eintrag erscheint im Store nicht, ein Recht ohne Eintrag wird nie erfragt.

| Angabe | Wozu sie da ist |
|---|---|
| Kennung und Fassung | Machen die App auf der Plattform und auf dem Display eindeutig. |
| Anzeige-Daten | Name, Einzeiler und Beschreibung — der Text, den Leserinnen und Leser im Store sehen. |
| Kategorie | Ordnet die App in eine der Kategorien des Stores ein und bestimmt zugleich ihren Abschnitt in der Widget-Palette des Szenen-Editors. |
| Klasse | Die Grundklasse ohne Marke, **Pro** oder **Add-on**. Sie entscheidet, welche Pakete die App enthalten. |
| Texte je Sprache | Die Texte stehen auf Deutsch im Manifest, jede weitere Sprache als eigener Block. Heute tragen alle Apps Deutsch und Englisch, der Store zeigt die Sprache des Portals. |
| Widget mit Ansichten | Jede Ansicht mit Bezeichnung, einem Satz Erklärung und ihrer Lage auf dem Display. Aus ihnen entstehen die **Ansichten** im Eintrag der App im Store. Sie sind keine gemalten Werbebilder, sondern dieselbe Anzeige-Technik wie am Display. |
| Kompatibilität | Auf welchen Gerätetypen die App läuft, in welcher Lage und was sie ohne Netz zeigt. Der Store nennt es unter **Läuft auf**. |
| Rechte | Wer im Team die App bedienen darf. Mit der Installation kommen sie in den Rechte-Katalog der Organisation. |
| Datenzugriff | Was die App liest, was sie nach außen überträgt und wozu, und was beim Deinstallieren mit ihren Daten geschieht. |
| Rechtlicher Hinweis | Der Hinweis samt Bedingungen, dem eine Organisation vor der Installation zustimmt — sofern die App einen trägt. |
| Signatur-Anforderung | Ob das Bündel dieser App zwingend signiert sein muss. |

Die Klasse deklariert die App selbst. Sie steht im Manifest und nicht im Preiskatalog: Die App weiß, was sie tut, der Katalog kennt Artikel und Mengen.

## Die vier Bausteine

| Baustein | Was er leistet |
|---|---|
| Manifest | Die deklarative Auskunft von oben. Jede App hat es. |
| Widget für den Bildschirm | Was am Ort zu sehen ist. Eine App trägt höchstens ein Widget. Mehrere Darstellungen löst sie über Vorlagen dieses einen Widgets. |
| Formular im Szenen-Editor | Womit Redakteurinnen und Redakteure das Widget einstellen. |
| Eigener Teil auf der Plattform | Optional: holt Daten von einer fremden Quelle, arbeitet nach Zeitplan und hält eigene Bestände, die die Organisation selbst pflegt. |

Eine App muss gar kein Widget tragen. Zwei der mitgelieferten bringen keine Fläche mit: Die eine sperrt eine Funktion des Portals auf, die andere liefert zusätzlich den Ort, an dem ein fremdes Speicherkonto angemeldet wird.

Drei der mitgelieferten Apps zeigen die drei Ausbaustufen: **Uhr** kommt mit Manifest, Widget und Formular aus und braucht keine Datenquelle. **Wetter** ergänzt den Abruf einer fremden Quelle. **Notdienst** trägt alles — Abruf, Zeitplan und eigene Bestände, die im Portal gepflegt werden.

Die mitgelieferten Apps sind die besten Vorbilder: Für jede Bauform gibt es unter ihnen ein Vorbild, und alle stehen im [App-Katalog](/docs/apps/der-katalog).

## Was Nutzer vor der Installation sehen

Drei Angaben entscheiden darüber, ob eine Organisation eine App installiert, und alle drei liefert die App selbst:

- **Rollen & Rechte** im Reiter **Einrichtung** des Store-Eintrags und im Zustimmungs-Dialog: wer im Team die App bedienen darf.
- **Daten & Zugriff** im gleichnamigen Reiter des Eintrags: was die App für die Organisation anlegt, was sie an vorhandenen Beständen liest, was sie beiträgt, mit welchem fremden Dienst sie spricht und was sie dabei überträgt, und was beim Deinstallieren bleibt. Der Abschnitt steht auch dann da, wenn die Antwort „nichts“ lautet.
- **Wichtiger Hinweis**: der rechtliche Hinweis, falls die App einen trägt. Ihm wird im Zustimmungs-Dialog ausdrücklich zugestimmt.

Wer hier ungenau bleibt, wird nicht installiert: Diese drei Angaben beantworten die Frage, die vor jeder Installation wirklich zählt. Die Kurzfakten der Handlungskarte, etwa **Eigene Daten**, **Nach außen** und **Läuft auf**, entstehen aus denselben Angaben des Manifests.

## Signieren und einreichen

Eine App wird als Bündel ausgeliefert und vom Gerät zur Laufzeit geholt. Ist das Bündel signiert, prüft das Gerät die Signatur, bevor es auspackt — für Apps mit sensiblen Inhalten ist das Pflicht, für die übrigen möglich. Was die Prüfung nicht besteht, läuft gar nicht erst an.

Der Weg in den Katalog führt über die Prüfung und Freigabe durch uns: Eine neue Fassung steht zuerst in einem Vorabkanal, und erst nach der Bestätigung durch eine zweite Person erreicht sie alle Organisationen. Wie das im Einzelnen geht, steht unter `https://developer.szenera.com/apps/von-der-vorlage-bis-zur-freigabe`. Apps von außen nehmen wir heute noch nicht an, das Einreichen kommt mit der Öffnung für Herausgeber.

## Weiterführendes

- [Was ist eine App, und was tut sie mit Ihren Daten?](/docs/apps/was-eine-app-ist)
- [Apps entdecken: Übersicht, Eintrag und Daten & Zugriff](/docs/apps/apps-entdecken)
- [Was können eigene Programme mit Szenera tun?](/docs/entwickler/was-es-gibt)