Wenn ein Projekt eine App im Store braucht, ist die Arbeit mit dem fertigen Build nicht getan. Zwischen dem letzten Commit und dem Eintrag im Store liegen Zertifikate, Signaturen, Store-Konten und Kennungen, die an jeder Stelle exakt gleich lauten müssen — und die erfahrungsgemäß auf einzelnen Rechnern landen: der Upload-Keystore im Download-Ordner, das Signaturzertifikat im Schlüsselbund einer Kollegin, die Bundle-ID in einer Notiz. Solange dieselbe Person jedes Release macht, fällt das nicht auf. Sobald jemand anderes übernimmt, beginnt die Suche.
Seit dem 1. August deckt die Plattform mehr Veröffentlichungswege ab als bisher — und verwaltet die zugehörigen Zugangsdaten an einer Stelle statt verteilt auf Arbeitsgeräte.
Native Projekttypen im Assistenten
Im Projekt-Assistenten stehen native iOS-Apps in Swift und native Android-Apps in Kotlin als eigene Projekttypen zur Verfügung, ergänzend zu Flutter und Expo. Das deckt auch den Fall ab, in dem ein plattformübergreifendes Framework nicht passt, etwa weil eine App tief in Systemfunktionen eingreift oder ein bestehendes natives Projekt weitergeführt wird.
Wählst du einen nativen Stack, schlägt die Plattform die passenden Werkzeuge vor: Xcode für iOS, Java für Android. Kotlin steht außerdem als Tech-Stack für Pakete zur Verfügung — relevant, wenn du eine Bibliothek pflegst, die mehrere Apps gemeinsam nutzen.
macOS: vier Veröffentlichungswege, einzeln konfigurierbar
Bei macOS gibt es nicht den einen Weg zur Veröffentlichung: Eine intern verteilte App hat andere Anforderungen als eine App im Mac App Store. Deshalb konfigurierst du vier Punkte unabhängig voneinander: Developer-ID-Signierung, Notarisierung, Mac App Store und öffentlicher Download. Ein internes Werkzeug bekommt Signierung, Notarisierung und einen Download-Link, ohne den Store zu berühren — beides im selben Projekt möglich.
Für Windows stehen Microsoft Store und Azure Artifact Signing als Anbindungen bereit.
-
App StoreApple-Releases mit vorbereiteten Metadaten und Assets.
-
Google PlayPlay-Store-Einträge automatisiert bespielt.
Store-Konten verknüpfen, statt Kennungen abzutippen
Verknüpfst du ein App-Store- oder Play-Store-Konto, lädt die Plattform die dort vorhandenen Apps. Bundle-ID und Paketname wählst du anschließend aus einer Liste aus, statt sie einzutragen.
Das klingt nach einer Kleinigkeit, ist im Alltag aber der häufigste Grund für abgebrochene Uploads: Ein Zeichen im Paketnamen weicht ab, und der Build läuft erst durch die gesamte Pipeline, bevor der Fehler sichtbar wird.
Importierte Android-Upload-Keystores lassen sich zudem wieder herunterladen — bei Android die Voraussetzung dafür, weiterhin Aktualisierungen für eine bestehende App zu veröffentlichen.
Builds in der CI, Veröffentlichung über Fastlane
Die Builds entstehen in der CI. Für iOS stehen macOS-Geräte bereit, sodass du keinen dauerhaft eingerichteten Rechner im Büro vorhalten musst. Die Veröffentlichung selbst läuft über Fastlane.
Der praktische Effekt: Ein Release hängt nicht an einem bestimmten Arbeitsplatz. Wer im Team die Berechtigung hat, kann es auslösen — eine Korrektur muss also nicht auf die Verfügbarkeit einer einzelnen Person warten.
Verwandte Themen
Wenn du bisher vor allem mit Flutter arbeitest, bleibt daran alles wie gehabt — die Seite zu Flutter CI/CD beschreibt diesen Weg. Die nativen Projekttypen kommen daneben hinzu, nicht an ihre Stelle. Wie der Weg vom Commit bis zum Store-Eintrag insgesamt aussieht, steht auf der Seite zur App-Store-Automatisierung.
