Wo fertige Builds landen und wie sie heißen, die Checkliste pro Build, alle Upload-Wege im Überblick, Release Notes, Git-Tag nach dem Upload und Auto-Upload.

Nach einem erfolgreichen Build kopiert die Build Station jedes Ergebnis in einen festen Sammelordner. Von dort geht es in die Stores: per Drag-and-drop, per Knopf in die Store-Webseite oder direkt über die Store-APIs.

Der Sammelordner

Vorgabe ist ~/Builds/iw-buildstation. Ändern kannst du das unter Einstellungen › Sammelordner im Feld Wurzel des Sammelordners und mit Übernehmen. Das Ordner-Symbol daneben öffnet ihn im Finder.

Jeder Build bekommt einen eigenen Ordner:

<Sammelordner>/<Projekt-ID>/<Preset-ID>/<Version>_<JJJJMMTT-HHMM>/
   kunde-a_1.4.2+87_android.aab
   build.log
   build.sh      (nur bei Inline-Scripts)
   meta.json

Der Dateiname folgt dem Muster <Projekt-ID>_<Version>+<Build-Nummer>_<Plattform> mit der ursprünglichen Endung.
build.log ist das vollständige Log des Builds.
meta.json enthält alle Daten des Laufs. Der Ordner bleibt damit auch ohne die App verständlich.

Die Station kopiert, sie verschiebt nicht. Das Original bleibt im build/-Ordner des Projekts.

Was abgelegt wird

flutter build ipa meldet zwei Ergebnisse: erst das .xcarchive, dann den Ordner mit der fertigen .ipa. Abgelegt wird die IPA. Nur wenn der Export aus dem Archiv nicht durchgelaufen ist, bleibt das Archiv übrig, als …_ios.xcarchive.zip mit einem Hinweis am Lauf.

Ordner-Ergebnisse, etwa ein Web-Build oder eine macOS-.app, werden gepackt und behalten ihre Endung im Namen. Im Verlauf steht an jedem Artefakt, woher die Station es kennt: vom Script gemeldet, aus der Flutter-Ausgabe, über artifactGlobs oder über den erwarteten Pfad.

Der Abschnitt „Hochladen”

Unter jedem erfolgreichen Build steht im Tab Build und im Verlauf der Abschnitt Hochladen, mit einem Eintrag pro Artefakt:

Griff zum Ziehen links: Zieh die Datei direkt aus der App ins Transporter-Fenster, in die Play Console im Browser oder in den Finder.
Transporter (nur bei .ipa): öffnet Transporter, legt den IPA-Pfad in die Zwischenablage und zeigt die Datei im Finder. Fehlt Transporter, ist der Knopf grau und nennt den Grund.
Play Console (bei .aab und .apk): öffnet den hinterlegten Track.
App Store Connect: für Processing und TestFlight-Freigabe.
Partner Center (bei .msix).
Manuell (bei Web-Builds, macOS-Apps und sonstigen Dateien): zeigt die Datei im Finder, für die Verteilung auf eigenem Weg.
Im Finder und Pfad kopieren.

Die Links auf Play Console und App Store Connect kommen aus den Store-Links im Projekt-Editor.

Direkt hochladen

Ist für das Projekt ein Upload-Weg eingerichtet, steht darunter Jetzt hochladen · … mit dem Namen des Wegs. Fehlt noch etwas, ist der Knopf gesperrt und daneben führt Einrichtung prüfen zurück in die Einrichtung. Gibt es noch keinen Weg, bietet Direkten Upload einrichten … ihn an.

Plattform	Wege
Android	Google Play API mit Service-Account, alternativ fastlane supply oder eine eigene Lane
iOS	xcrun altool mit App-Store-Connect-Team-Schlüssel, alternativ eine eigene fastlane-Lane
Windows	Partner Center API für eine fertige `.msix`
macOS	Mac App Store, GitHub-Release oder HTTPS-Webhook, siehe macOS-Apps verteilen
alle	kein Upload: nur Drag-and-drop und Store-Links (Voreinstellung)

Die Store-APIs spricht die Station selbst an, ohne fastlane und ohne Codemagic. Die Zugangsdaten liegen pro Projekt im macOS-Schlüsselbund, nie in der Konfiguration. Eingerichtet wird das unter Projekt bearbeiten › Upload › Store-Upload einrichten.

Vor dem Upload

Die Rückfrage Hochladen nach …? zeigt den exakten Befehl bzw. die API-Aufrufe, wie bei einem Build. Vorher prüft die Station alles, was sich ohne Ausführung prüfen lässt: fehlende IDs, Zugangsdaten, die nicht im Schlüsselbund liegen, verschwundene Artefakte.

Hochladen reiht den Upload in die Warteschlange ein. Er landet mit vollständigem Log im Verlauf, wie ein Build. Läuft für das Projekt gerade etwas, heißt der Knopf Upload zur Warteschlange.

Ein API-Upload lässt sich bis kurz vor dem Festschreiben abbrechen. Danach liegt er beim Store.

Release Notes

Im Feld Release Notes (optional) der Rückfrage trägst du ein, was neu ist, mit bis zu 500 Zeichen:

Bei Google Play über die API gehen sie als „Neu in dieser Version” an den Track.
Bei TestFlight gehen sie als „Was ist zu testen”. Dafür müssen im Projekt Bundle-ID und Issuer-ID eingetragen sein.
Bei macOS im Direktvertrieb erscheinen sie im Sparkle-Update-Fenster.

Die Sprache steht im Hinweis unter dem Feld, Vorgabe ist de-DE. Andere Upload-Wege übertragen keine Release Notes, das Feld ist dann gesperrt.

Aus Commits vorschlagen (KI) schreibt einen Entwurf aus den Commit-Betreffzeilen seit dem letzten Upload in denselben Store. Dafür braucht es den Claude-API-Schlüssel aus Einstellungen › KI-Reparatur. Gesendet werden nur die Betreffzeilen, kein Code und keine Dateien. Den Vorschlag prüfst du vor dem Hochladen.

Automatisch hochladen

Unter Projekt bearbeiten › Upload gibt es den Schalter Erfolgreiche Builds automatisch hochladen. Ist er an, landen AAB, IPA und macOS-App nach jedem erfolgreichen Build ohne Rückfrage in den eingerichteten Stores.

Pro Store wird genau ein Artefakt hochgeladen, bei Android das AAB vor dem APK.
Eine Build-Nummer, die dort schon liegt, wird übersprungen.
Fehlen Zugangsdaten, wird ebenfalls übersprungen.
Was übersprungen wurde, steht als Hinweis am Build.

Im Tab Build zeigt ein Chip Auto-Upload, dass der Schalter an ist.

Prüf Einstellungen und Ergebnisse, bevor du Uploads automatisch laufen lässt. Was hochgeladen wird, verantwortest du.

Git-Tag nach dem Upload

Nach einem erfolgreichen Upload setzt die Station ein Git-Tag auf den Commit des Builds:

<projekt>/<version>+<build>    z. B. kunde-a/1.4.2+87

So bleibt im Repository sichtbar, welcher Stand beim Kunden liegt. Das Tag trägt als Nachricht Projekt, Version, Store und gegebenenfalls die Release Notes.

Gesteuert wird das unter Einstellungen › Nach dem Upload:

Git-Tag setzen (Vorgabe an)
Tag nach origin pushen (Vorgabe an)

Zeigt ein Tag gleichen Namens schon auf einen anderen Commit, wird es nicht verschoben. Scheitert das Taggen oder der Push, bleibt der Upload trotzdem erfolgreich, und der Grund steht am Lauf.

Die Checkliste pro Build

Jeder Build bekommt eine Checkliste, passend zur Plattform. Für Android:

Build erfolgreich
Version/Build-Nummer geprüft
AAB in Play Console hochgeladen
Release Notes eingetragen
Internal-Testing-Track freigegeben
Kunde informiert

Für iOS, Web und macOS gibt es eigene Vorlagen, etwa mit „Processing in App Store Connect abgeschlossen” oder „Smoke-Test auf der Zielumgebung”.

Build erfolgreich hakt die Station selbst ab. Nach einem erfolgreichen Upload über die Station hakt sie auch Version/Build-Nummer geprüft und den Hochladen-Schritt ab, denn der Store hat die Nummer angenommen. Den Rest hakst du von Hand ab, im Verlauf oder bequemer in der Arbeitsliste Offen, siehe Übersicht und Arbeitsliste.

Unter der Checkliste steht ein Feld Notizen für Ticketnummern, Kundenkontakt oder Besonderheiten.

Artefakte aus Codemagic

Auch Builds aus Codemagic landen im Sammelordner, unter <Projekt-ID>/codemagic/. Von dort lassen sie sich mit In den Store direkt hochladen. Siehe Codemagic.

Alte Artefakte

Artefakte bleiben liegen, bis du sie löschst. Unter Aufräumen › Artefakte und Logs der Build Station legst du fest, wie viele Tage und wie viele Builds pro Preset du behältst. Siehe Platz freiräumen.

Artefakte und Upload