React-Native-Releases automatisieren: Screenshots, Metadaten und Store-Upload
Ein Befehl erzeugt Ihre Store-Screenshots in allen Sprachen, einer das Preview-Video, einer lädt Metadaten hoch, einer schickt den Build zu TestFlight — reproduzierbar statt jedes Mal von Hand.
Eine App zu veröffentlichen ist selten das Problem. Sie ein zweites, fünftes und zwanzigstes Mal zu veröffentlichen ist eines: Screenshots von Hand nachstellen, Store-Texte aus einer Tabelle ins Backend tippen, und beim Upload feststellen, dass ein Schlüssel abgelaufen ist.
Wir bauen diesen Ablauf als Pipeline im Projekt. Ein UI-Test fährt die App durch jeden Screen und erzeugt die Store-Bilder in allen Sprachen, gerahmt und beschriftet. Store-Texte liegen als versionierte Dateien im Repository statt in einem Dokument. Jeder Schritt — Metadaten, Screenshots, TestFlight, Einreichung — lässt sich einzeln auslösen, damit eine Korrektur an der Beschreibung nicht durch die Prüfung muss.
Wir schauen zuerst an, was bei Ihrem letzten Release von Hand passiert ist.
Was Sie bekommen
Screenshots aus einem Testlauf
Ein UI-Test fährt die App durch jeden Screen und löst die Aufnahme aus. Neue Sprache, neues Gerät, geänderter Screen — ein Befehl, nicht ein Nachmittag.
Jeder Schritt einzeln auslösbar
Metadaten ändern, ohne einen Build hochzuladen. Screenshots tauschen, ohne etwas zur Prüfung einzureichen. Eingereicht wird nur, wenn Sie es ausdrücklich meinen.
Gleiches Ergebnis bei jedem Lauf
Simulator gelöscht, App neu installiert, Statusleiste vereinheitlicht, Demodaten gesetzt. Zwei Läufe liefern dieselben Bilder — nicht ähnliche.
Für wen geeignet
Teams, die regelmässig veröffentlichen
Wenn alle paar Wochen ein Update rausgeht und jedes Mal dieselben Handgriffe anfallen.
Apps in mehreren Sprachen
Wenn Screenshots und Store-Texte pro Sprache gepflegt werden müssen und der Aufwand mit jeder Sprache linear wächst.
Solo-Entwickler und kleine Teams
Wenn der Release an einer Person hängt und niemand sonst ihn durchführen könnte.
Agenturen mit App-Kunden
Wenn Sie die Kundenbeziehung halten und die Release-Technik im Hintergrund erledigt haben wollen.
Der Release kostet jedes Mal wieder zwei Tage
Die App ist fertig, der Code steht. Was den Termin frisst, ist alles drumherum — und es kommt bei jedem Update in voller Länge zurück, weil beim letzten Mal niemand aufgeschrieben hat, wie es ging.
Screenshots von Hand
Simulator starten, durchklicken, Bildschirmfoto, zuschneiden. Mal zwei Sprachen, mal zwei Plattformen, und nach jeder Designänderung von vorne.
Bilder, die nicht zusammenpassen
Auf einem Screenshot ist es 14:37 und der Akku halb leer, auf dem nächsten steht anderer Beispieltext. Auf der Store-Seite nebeneinander fällt genau das auf.
Übersetzungen leben in einer Tabelle
Beschreibung, Keywords und Untertitel pro Sprache werden in ein Dokument getippt und später von Hand ins Store-Backend kopiert. Was zuletzt hochgeladen wurde, weiss niemand sicher.
Alles hängt an einer Person
Zertifikate, Schlüssel und der genaue Ablauf liegen in einem Kopf oder einem Chatverlauf. Ist diese Person im Urlaub, verschiebt sich der Release.
Fehler fallen erst beim Hochladen auf
Ein abgelaufener Schlüssel oder ein falscher App-Datensatz zeigt sich mitten im Upload — nachdem der Build schon eine halbe Stunde gelaufen ist.
Ein Tippfehler bedeutet neue Prüfung
Wer Text und Binary zusammen einreicht, muss für jede Korrektur an der Beschreibung erneut durch die Prüfung.
Meist zeigt schon die Liste der Handgriffe, wo die zwei Tage hingehen.
Was wir einrichten
Die Pipeline wird aus einzeln auslösbaren Schritten gebaut, nicht als ein grosser Knopf. Das ist der Unterschied zwischen "Metadaten korrigieren" und "neuen Release starten".
Screenshots erzeugen
Ein UI-Test fährt die App durch die definierten Screens und löst an jeder Stelle die Aufnahme aus — in jeder eingerichteten Sprache, auf den Geräten, die der Store verlangt.
Rahmen und Beschriftung
Die Rohaufnahmen bekommen Gerätrahmen, Hintergrund und eine Bildunterschrift je Sprache. Hochgeladen werden nur die fertig gerahmten Dateien, nie die Rohbilder daneben.
Metadaten aus dem Repository
Name, Untertitel, Keywords, Beschreibung und Release-Notes liegen als Textdateien pro Sprache im Projekt — versioniert, überprüfbar im Diff, nicht in einem Dokument.
Schlüssel vorher prüfen
Ein eigener, schreibfreier Schritt bestätigt, dass der Store-Schlüssel gültig ist und der App-Datensatz existiert — bevor ein Upload eine halbe Stunde läuft und dann abbricht.
TestFlight
Build erzeugen und zu TestFlight hochladen, inklusive Tester-Hinweisen in jeder Store-Sprache statt eines englischen Platzhalters.
Einreichen als eigener Schritt
Binary, Metadaten und Screenshots zusammen zur Prüfung — getrennt von allem anderen, damit nichts versehentlich eingereicht wird.
Versionen und Build-Nummern
Hochzählen und Taggen laufen im selben Ablauf, damit Store-Version, Git-Tag und Release-Notes nicht auseinanderlaufen.
App-Preview-Video
Aus Simulator-Mitschnitten entsteht das Store-Video pro Sprache — Layout, Beschriftung und Endbild aus einer Konfigurationsdatei, nicht aus einem Schnittprogramm.
Welche dieser Schritte Sie brauchen, hängt davon ab, wie oft Sie veröffentlichen.
Warum die Screenshots reproduzierbar sind
Reproduzierbar heisst: zwei Läufe liefern identische Bilder. Das ist kein Nebeneffekt, das sind vier bewusste Entscheidungen.
Sauberer Startzustand
Der Simulator wird gelöscht und die App neu installiert, bevor ein Lauf beginnt. Keine Reste aus dem letzten Test, keine halb ausgefüllten Formulare.
Eigener Screenshot-Modus
Die App startet mit gesetzten Demodaten statt mit leeren Listen oder dem Zufall des letzten Tests. Auf jedem Bild stehen dieselben Beispiele.
Vereinheitlichte Statusleiste
Volle Batterie, voller Empfang, feste Uhrzeit auf jedem Bild — statt des Zustands, den der Simulator zufällig gerade hatte.
Feste Geräte und Laufzeiten
Gerät und iOS-Version werden eindeutig festgelegt. Heissen zwei Simulatoren gleich, wird nicht über den Namen aufgelöst, sondern über die Kennung.
Das App-Preview-Video
Das Store-Video ist der Teil, den fast alle von Hand machen und danach nie wieder anfassen. Es lässt sich genauso bauen wie die Screenshots — aus Mitschnitten und einer Konfigurationsdatei.
Mitschnitt statt Bildschirmaufnahme von Hand
Der Simulator nimmt auf, während die App läuft. Werden zwei Geräte nebeneinander gezeigt, laufen beide Aufnahmen gleichzeitig und sind dadurch von sich aus synchron.
Timing bleibt unangetastet
Nichts wird nachträglich verlangsamt oder gekürzt. Bei einer App, deren Inhalt vom Takt lebt, würde jede Retusche das Produkt falsch darstellen — die Zeit für Beschriftungen kommt aus dem Mitschnitt selbst.
Beschriftung je Sprache
Texte und Endbild kommen pro Sprache aus einer Datei. Auch Japanisch und Chinesisch werden sauber gesetzt, wofür eine eigene Schriftart nötig ist.
Startbild bewusst gewählt
Das Einzelbild, auf dem die Store-Seite stehen bleibt, wird als fester Zeitpunkt festgelegt statt dem Zufall überlassen.
Hochladen, wo fastlane aufhört
Für Screenshots gibt es fertige Wege, für Preview-Videos nicht — genau hier bleiben die meisten stecken. Wir laden das Video direkt beim Store hoch, standardmässig als Probelauf, und ersetzen dabei nur die Videos einer Sprache.
Wir sagen vorab, welcher Teil automatisch läuft und welcher Handarbeit bleibt.
Was nicht dazugehört
Damit der Rahmen klar ist — das sind eigene Themen:
Die App selbst entwickeln
Diese Leistung setzt eine lauffähige App voraus. Fehlt noch Funktionalität, ist das ein Entwicklungsprojekt.
Übersetzen
Wir richten die Struktur je Sprache ein und laden hoch, was darin steht. Die Übersetzung selbst kommt von Ihnen oder Ihrem Übersetzungsbüro.
Grafikdesign der Screenshots
Rahmen, Hintergrund und Beschriftung setzen wir technisch um. Wie die Bildsprache aussehen soll, entscheiden Sie oder Ihre Designabteilung.
Eine Freigabe zusichern
Über die Prüfung entscheidet der Store. Die Pipeline sorgt dafür, dass die Einreichung vollständig und wiederholbar ist, nicht dafür, dass sie angenommen wird.
Ablauf
Bestandsaufnahme
Wir gehen den letzten Release durch und halten fest, welcher Handgriff von Hand passiert ist und wie lange er gedauert hat.
Zugänge und Schlüssel
Store-Schlüssel, Zertifikate und Signierung werden eingerichtet und dokumentiert — auf Ihre Accounts, nicht auf unsere.
Screens festlegen
Gemeinsam bestimmen wir, welche Screens auf die Store-Seite gehören und in welcher Reihenfolge. Daraus entsteht der Testablauf.
Aufnahme und Rahmen bauen
Der UI-Test wird geschrieben, der Screenshot-Modus mit Demodaten eingerichtet und die Rahmung je Sprache eingestellt.
Metadaten überführen
Vorhandene Store-Texte wandern als Dateien ins Projekt, pro Sprache, damit Änderungen künftig im Diff sichtbar sind.
Durchspielen und übergeben
Ein vollständiger Durchlauf bis TestFlight, dann eine kurze Anleitung, mit der Ihr Team den nächsten Release allein fährt.
Sie erfahren vorab, welche Zugänge nötig sind und was Ihr Team beisteuert.
Warum sich das nach zwei Releases gerechnet hat
Der Aufwand fällt einmal an, die Ersparnis bei jedem Update danach:
Aus Tagen werden Befehle
Was pro Release manuell anfällt, fällt danach nicht mehr an — unabhängig davon, wie viele Sprachen dazukommen.
Designänderungen kosten nichts mehr
Wird ein Screen umgebaut, laufen die Screenshots neu durch, statt dass jemand vierzehn Bilder nachstellt.
Der Release hängt nicht mehr an einer Person
Der Ablauf steht dokumentiert im Projekt, nicht in einem Kopf. Urlaub verschiebt keinen Termin mehr.
Weniger Runden bei der Prüfung
Vollständige, wiederholbare Einreichungen vermeiden die Ablehnungen, die aus fehlenden Angaben entstehen.
Häufige Fragen
Läuft das auch für Android?
Ja, mit demselben Werkzeug. Die Abläufe unterscheiden sich — Play Console statt App Store Connect, andere Bildgrössen, andere Metadatenfelder — aber Screenshots, Store-Texte und Upload lassen sich genauso automatisieren.
Wir haben nur zwei Sprachen. Lohnt sich das?
Meist ab dem zweiten Release, unabhängig von der Sprachzahl. Der Aufwand von Hand fällt bei jedem Update erneut an, der Aufbau nur einmal. Bei einer App, die einmal erscheint und danach ruht, sagen wir Ihnen, dass es sich nicht lohnt.
Was ist ein Screenshot-Modus?
Ein Startzustand, in dem die App feste Demodaten lädt statt echter oder leerer Inhalte. Dadurch steht auf jedem Bild dasselbe Beispiel, in jeder Sprache — statt dessen, was im Simulator zufällig übrig war.
Müssen wir unsere App dafür umbauen?
Nein, aber ein kleiner Eingriff gehört dazu: Die App braucht einen Startschalter für den Screenshot-Modus und stabile Kennungen an den Elementen, die der Test ansteuert. Beides ist additiv und stört den normalen Betrieb nicht.
Können wir Metadaten ändern, ohne neu einzureichen?
Ja, das ist einer der Hauptgründe für getrennte Schritte. Store-Texte und Screenshots lassen sich hochladen, ohne einen Build mitzuschicken und ohne etwas zur Prüfung freizugeben.
Wer besitzt die Schlüssel und Zertifikate?
Sie. Store-Account, Schlüssel und Zertifikate laufen auf Ihren Namen. Wir richten sie ein, dokumentieren, wo sie liegen, und arbeiten mit den Zugängen, die Sie uns geben.
Können Sie auch das App-Preview-Video automatisieren?
Ja, und zwar bis zum Upload. Aus den Mitschnitten baut ein Skript das fertige Video je Sprache — Layout, Beschriftung, Endbild und Startbild kommen aus einer Konfigurationsdatei, sodass eine neue Sprache ein Eintrag ist und kein Schnitttermin. Handarbeit bleibt, was inhaltlich entschieden werden muss: was gezeigt wird und wie die Aufnahme abläuft.
Läuft das auf unserem Rechner oder bei Ihnen?
Auf Ihrem, und das ist Absicht. Die Pipeline liegt im Repository und braucht einen Mac mit Xcode. Damit bleibt sie auch dann nutzbar, wenn wir nicht mehr im Projekt sind.
Was passiert bei einem neuen iPhone-Format?
Gerät und Laufzeit stehen an einer Stelle in der Konfiguration. Kommt ein Format dazu, wird es dort ergänzt und der nächste Lauf erzeugt die Bilder mit. Das ist eine Zeile, kein neuer Nachmittag.
Wie lange dauert die Einrichtung?
Das hängt von der Anzahl der Screens, Sprachen und Plattformen ab. Wir sagen es Ihnen nach der Bestandsaufnahme — und nennen dabei auch die Punkte, die bei Ihnen schneller gehen als üblich, statt eine Pauschale zu nennen.
Wie lange dauert Ihr nächster Release?
Schicken Sie uns kurz, was bei Ihrem letzten Update von Hand passiert ist. Wir sagen Ihnen, welche Schritte sich automatisieren lassen und welche Handarbeit bleibt.
