Seine App endlich in einem Store zu veröffentlichen ist ein großer Schritt. Aber noch wichtiger sind tatsächlich regelmäßige Updates. Ich bin bemüht nicht zu vergessen, wie genau ich das anstelle, immerhin gibt es auch noch verschiedene Plattformen zu berücksichtigen, wenn das also kein Grund für diesen Beitrag ist, dann weiß ich auch nicht.
Das Problem
Besonders ein Framework wie Flutter bekommt im Monat mehrere Updates. Ebenso genutzte Plugins und Dependencies. Das allein sollte Grund genug sein für ein monatliches Update. Außerdem hab ich mal gelesen, dass sich das positiv auf die Positionierung im Store auswirkt…
Jetzt gibt es den Apple-Store, Play-Store, eine gehostete Web-App und bald noch Desktop-Apps. Ich kann nicht die einzige sein, die regelmäßig vor ihrer Entwicklungsumgebung sitzt und sich denkt „verdammt, ich hab das erst letzten Monat gemacht, welchen Knopf muss ich nochmal drücken…“
Zu aller erst muss die zu veröffentliche Version geprüft werden. Mit Emulator, Geräten, im Browser, auf dem Desktop. Und das nur ergänzend zu Tests und Versions-Management.
Play-Store Update
Vor dem Erstellen einer neuen Version muss der Versionsname und Versionscode der aktuellen App abgeglichen werden, um Komplikationen zu vermeiden.
Signed Bundle bauen
Der Google-Play-Store benötigt eine apk-Datei oder ein App-Bundle, das in das Release eingefügt wird. Um dies zu erhalten muss man sein Projekt zunächst einmal in Android Studio öffnen (um genau zu sein das Android-Verzeichnis des Projekts).
Wenn irgendwo Test-IDs genutzt werden, z.B. für Werbung, immer daran denken, diese vorher zu ersetzen.
Die Datei local.properties öffnen, um die Release-Informationen anzupassen.
flutter.buildMode=release
flutter.versionName=2.0.2
flutter.sdk=/Library/flutter
sdk.dir=/Users/erdbaerchen/Library/Android/sdk
flutter.versionCode=42Der Versionscode muss höher sein als jeder der aktuell veröffentlichten App.
Um die Build-Datei zu generieren Build > Generate Signed Bundle / APK. Das dauert ein bisschen, danach kann der locate-Link im Event-Log genutzt werden, um den Ordner mit der neuen App-Datei direkt zu öffnen.
Neues Release erstellen
Je nachdem was für eine Art Track veröffentlich werden soll kann „Produktion“, „Offener Test“ (Beta) oder „Geschlossener Test“ ausgewählt werden. Das neue Releasee wird mit dem großen, blauen Button oben rechts erstellt.
App Bundle oder APKs hochladen, am einfachsten per Drag-and-Drop aus dem im letzten Schritt geöffneten Ordner. Die Datei wird hochgeladen und daraufhin als neuer Build-Eintrag unterhalb des Feldes angezeigt. Der Release-Name wird automatisch aus der Datei gezogen. Dann sollten noch Release-Notes eingepflegt werden um zu zeigen, welche Änderungen diese neue Version mit sich bringt. Diese werden auch später im Store angezeigt.
Jetzt Speichern, Überprüfen und Veröffentlichen, um die neue App-Version auf den Weg zu schicken. Abhängig von der App-Größe kann das eine Stunde oder länger dauern.
Sobald das Update im Store verfügbar ist wird dies in der Releases-Liste angezeigt.
App-Store Update
Der erste Schritt wird in Xcode durchgeführt. Wieder gilt es Build- und Versions-Nummer zu prüfen.
Wenn irgendwo Test-IDs genutzt werden, z.B. für Werbung, immer daran denken, diese vorher zu ersetzen.
Archiv bauen
Um die richtigen Dateien zu nutzen, den Runner des Projects auswählen und Any iOS Device als Build-Ziel auswählen. Im General-Reiter kann noch einmal überprüft werden, dass Version und Build-Nummer höher sind als die der aktiven Version im App-Store.
Product > Archive baut ein neues Archiv. Wurde der Build erfolgreich abgeschlossen öffnet sich ein Fenster mit einer Liste der Archive. Eine weitere Chance, um Build- und Versionsnummer zu überprüfen. Distribute App klicken, um fortzufahren. Es folgt ein Wizard, nach dem das Archiv bereit ist für den Upload. Das dauert eine Weile…
Entweder gibt es einen Fehler, oder eine hübsche Zusammenfassung der App, die man gerade hochladen möchte. Upload anklicken. Und warten.
Nachdem die Meldung „successfully uploaded“ angezeigt wird, Done klicken und weiter zum nächsten Schritt.
Xcode sendet den neuen Build direkt zum App-Store. Aber das kann einige Minuten Dauern. In der Zwischenzeit kann schon einmal das nächste Release vorbereitet werden.
Es ist gut möglich, dass man mehrere E-Mails erhält, die auf Verbesserungen hinweisen oder Fehler aufzeigen, die eine Ablehnung der App bedeuten.
Neuen Release erstellen
App Store Connect im Browser öffnen und zur App navigieren. Unterhalb des App-Titels auf + klicken um einen neuen Release anzulegen.
Release-Informationen einpflegen. Um den frisch hochgeladenen Build einzufügen muss abgewartet werden, bis er bestätigt wurde.
Sobald eine E-Mail kommt die enthält „has completed processing„, kann der Build von App Store Connect ausgewählt werden.
Build auswählen, speichern und „Enter for processing“ auswählen. Unterhalb des App-Titels wird der Zustand der Releases angezeigt. Außerdem kommt eine E-Mail die mitteilt, dass die App verarbeitet wird: Waiting for Review.
Warten
Es kommen ganze 5 E-Mails im Verlauf des Veröffentlichungs-Prozesses an.
Diejenige welche enthält, dass die App „Ready for Sale“ ist, ist vorerst die letzte. Jetzt können die Benutzer ihre Apps mit der neuen Version updaten.
Meiner Erfahrung nach dauert dieser Schritt mindestens einen halben Tag.
Web Update
Web-Dateien erstellen
Im Terminal der IDE flutter build web ausführen. Dies erstellt die Build-Dateien im /web Ordner des Projekts.
Mit dem FTP-Client der Wahl eine Verbindung zum Web-Hosting herstellen. Die neuen Dateien hochladen und im Browser überprüfen, ob alles geklappt hat.