Veröffentlichen & Prüfung
Im Studio arbeitest du an einem Entwurf. Mitglieder sehen ihn nie – sie öffnen immer eine Version, die Artim geprüft und freigegeben hat. Diese Seite erklärt Versionen, die Prüfung und was ein Eintrag braucht, damit er im App Store für alle Vereine erscheint.
Versionen
Eine Version friert den aktuellen Entwurf ein – app.json, main.js, styling.css und alle weiteren Dateien – und reicht ihn zur Prüfung ein. Du veröffentlichst sie im Studio unter Versionen → Version veröffentlichen.
| Regel | Wert |
|---|---|
| Format | Semver MAJOR.MINOR.PATCH, z. B. 1.4.0 – ohne v, ohne Zusätze wie -beta |
| Reihenfolge | jede Version muss höher sein als alle bisherigen |
| Änderungstext | Pflicht, mindestens drei Zeichen, höchstens 2.000. Die Prüfung liest ihn mit. |
| Entwurf | höchstens 512 KB für alle Dateien zusammen; ein ungültiges app.json lässt sich nicht veröffentlichen |
| Unveränderlich | eine veröffentlichte Version ändert sich nie mehr. Für eine Korrektur veröffentlichst du die nächste. |
Wann du welche Stelle erhöhst:
| Änderung | Beispiel | Version |
|---|---|---|
| Fehlerkorrektur, Texte, Farben | Tippfehler, anderes Blau | 1.0.0 → 1.0.1 |
| Neue Funktion, gleiche Berechtigungen | zusätzlicher Export | 1.0.1 → 1.1.0 |
| Neue Berechtigungen oder grundlegend neu | App liest jetzt auch Termine | 1.1.0 → 2.0.0 |
Neue Scopes bedeuten für jedes Mitglied „Zugriff erweitern“ beim nächsten Öffnen – ein guter Grund für eine neue Hauptversion und einen klaren Änderungstext.
Prüfstatus
| Status | Anzeige | Bedeutung |
|---|---|---|
pending | In Prüfung | eingereicht, noch nicht entschieden |
approved | Freigegeben | die Version darf laufen |
rejected | Abgelehnt | die Version läuft nie; der Grund steht daneben |
Den Stand siehst du im Studio unter Versionen und im DevHub unter Methacore-App → Prüfung je Version. Ändern lässt er sich dort nicht – die Entscheidung trifft Artim, und sie erscheint nach spätestens einer Minute auf beiden Seiten.
Live ist immer die höchste freigegebene Version. Reichst du 1.1.0 ein, laufen alle weiter mit 1.0.0, bis 1.1.0 freigegeben ist – ohne Lücke. Wird 1.1.0 abgelehnt, bleibt 1.0.0 live.
Eine gehostete App ohne freigegebene Version lässt sich nicht öffnen, auch nicht im eigenen Verein. Zum Ausprobieren gibt es die Vorschau im Studio.
Was die Prüfung ansieht
Die Prüfung durch Artim schaut sich jede Version einer gehosteten App an, bevor sie live geht:
- Tut die App, was Eintrag und Änderungstext versprechen?
- Verlangt sie nur die Berechtigungen, die sie wirklich braucht?
- Geht sie mit den Daten der Mitglieder so um, wie es ihre Datenschutzerklärung sagt – und legt sie keine unnötigen Kopien im App-Speicher an?
- Enthält sie nichts, was Mitglieder täuscht, etwa nachgebaute Anmeldeformulare oder versteckte Funktionen?
- Funktioniert sie auf der angegebenen Plattform, im hellen und im dunklen Thema?
Bei einer Ablehnung steht der Grund am Prüfstatus. Behebe ihn und reiche die nächste Version ein.
Was „Von Methacore geprüft“ bedeutet
Das Siegel trägt eine App, wenn beides stimmt:
- sie ist gehostet – ihr Code liegt bei Methacore und läuft in der Sandbox mit fester Sicherheitsrichtlinie,
- ihre Live-Version ist freigegeben – genau dieser Code wurde geprüft.
Das Siegel sagt Mitgliedern: Diese Fassung hat jemand angesehen, sie kann nur mit Methacore und dem DevHub sprechen, und sie ändert sich nicht, ohne erneut geprüft zu werden. Es ist keine Garantie für Fehlerfreiheit und keine Aussage über den Anbieter.
Externe Apps tragen das Siegel nie. Ihr Code liegt auf deinem Server und kann sich jederzeit ändern. Artim prüft bei ihnen den Eintrag und die Angaben zum Anbieter, bevor sie für andere Vereine erscheinen, nicht aber den Code. Im Store steht deshalb „Extern – nicht von Methacore geprüft“.
Öffentlich im App Store
Ohne den Schalter „Öffentlich im App Store anbieten“ sieht nur der Verein, der mit deinem DevHub-Projekt verknüpft ist, die App. Mit dem Schalter erscheint sie in jedem Verein, dessen Richtlinie sie zulässt – sobald sie freigegeben ist.
Ein öffentlicher Eintrag braucht:
| Feld | Regel |
|---|---|
| Name | Pflicht, höchstens 60 Zeichen |
| Kurzbeschreibung | Pflicht, höchstens 140 Zeichen – ein Satz, der sagt, was die App tut |
| Ausführliche Beschreibung | Pflicht, höchstens 4.000 Zeichen: Funktionen, Zielgruppe, genutzte Daten |
| Kategorie | Pflicht: Export, Training, Kommunikation, Spiel, Verwaltung, Veranstaltungen oder Sonstiges |
| Icon | Pflicht, quadratisch, mindestens 512 × 512 Pixel, PNG, JPEG oder WebP |
| Screenshots | mindestens einer, höchstens 8; die Reihenfolge ist die im Store |
| Tags | optional, bis zu 10 mit je höchstens 30 Zeichen |
| Externe Adresse | nur bei externen Apps: https, auf einer autorisierten Domain |
Dazu kommen die Angaben zum Anbieter aus dem DevHub-Projekt: Datenschutzerklärung und Nutzungsbedingungen (beide Pflicht für produktive OAuth-Clients), Support-E-Mail und Logo. Mitglieder sehen sie in der Detailansicht und in der Zustimmung.
Gute Screenshots
- echte Oberfläche der App, keine Werbegrafik
- im Seitenverhältnis der Zielplattform: Querformat fürs Dashboard, Hochformat fürs Handy
- Beispieldaten ohne echte Namen und E-Mail-Adressen
Zusammengefasst
- Im Studio bauen, in der Vorschau testen.
- Version veröffentlichen mit Semver und Änderungstext.
- Prüfstatus im Studio oder DevHub verfolgen.
- Nach der Freigabe ist die Version live – im eigenen Verein sofort, mit „Öffentlich“ auch überall sonst.