Presets

Ein Preset ist eine benannte Build-Konfiguration, zum Beispiel „Android – Play Store (AAB)” oder „iOS – TestFlight”. Ein Projekt hat beliebig viele davon. Im Tab Build wählst du eins aus, prüfst die Version und startest.

Presets legst du im Projekt-Editor an: Projekt bearbeiten im Tab Build, dann im Abschnitt Presets auf + Preset. Ein vorhandenes Preset öffnest du dort über das Stift-Symbol oder direkt im Tab Build über den Bearbeiten-Knopf am angezeigten Befehl. Viele Presets entstehen schon beim Anlegen des Projekts aus den Vorschlägen des Assistenten.

Die zwei Modi

Modus	Wofür
Flutter-Befehl	Die Kommandozeile entsteht aus den Formularfeldern, etwa fvm flutter build appbundle --release --flavor kundeA.
Eigenes Script	Ein frei definiertes Shell-Script, inline gepflegt oder als Datei im Repository.

Dart-Defines, Env, Flavor, Target, Version und Pre-Steps gelten in beiden Modi. Im Script-Modus kommen sie als BS_*-Umgebungsvariablen beim Script an, statt in eine Kommandozeile zu fließen. Das hält die Historie vergleichbar. Alles zum Script-Modus steht unter Eigene Scripts und Web-Builds.

Die Felder

Oben im Editor stehen Preset-Name, ID und Plattform (Android, iOS, Web, macOS oder Sonstige). Darunter wählst du den Modus.

Im Modus „Flutter-Befehl”

Feld	Wirkung
Output-Typ	App Bundle (.aab), APK (.apk), IPA (.ipa), Web oder macOS (.app)
Build-Mode	Release, Profile oder Debug
Flavor	leer heißt: ohne --flavor
Target (-t)	Einstiegspunkt, z. B. lib/main_kunde_a.dart. Die gefundenen Entry-Points stehen in einem Auswahlmenü.
–dart-define-from-file	Datei mit Dart-Defines, relativ zum Projekt
–export-options-plist	nur bei IPA, z. B. ios/ExportOptions.plist

--dart-define-from-file ist der empfohlene Weg für Geheimnisse. Die Station liest die Datei nie, sie reicht nur den Pfad weiter. Halte die Datei per .gitignore aus dem Repository.

In beiden Modi

Abschnitt	Inhalt
Dart-Defines	Compile-Time-Konstanten in der App (String.fromEnvironment). Die Default-Dart-Defines des Projekts gelten mit und lassen sich hier überschreiben.
Env	Prozess-Umgebung für die Toolchain, etwa JAVA_HOME oder DEVELOPER_DIR. Landet nicht in der App.
Pre-Steps	Schritte vor dem Build (siehe unten)
artifactGlobs	Muster, unter denen die Station nach Artefakten sucht, z. B. build/app/outputs/**/*.aab
Extra-Args	zusätzliche Argumente an flutter build, z. B. --obfuscate (nur im Modus „Flutter-Befehl”)

Werte, deren Schlüssel nach Geheimnis aussieht (KEY, SECRET, TOKEN, PASSWORD, DSN), zeigt die Station maskiert an. Das schützt vor Blicken über die Schulter, ist aber keine Verschlüsselung.

Sonstiges

• Build-Nummer automatisch hochzählen zählt gegenüber dem letzten erfolgreichen Build dieses Presets hoch, nicht gegenüber der pubspec.yaml. Liegt im Store schon eine höhere Nummer, zählt die Station über diese hinaus, damit der Upload nicht am Ende scheitert.
• Timeout (Minuten) bricht einen hängenden Build ab. Leer heißt: kein Timeout.

Pre-Steps

Pre-Steps laufen vor dem eigentlichen Build. Zur Wahl stehen:

Schritt	Was er tut
clean	löscht build/ und .dart_tool, kostet mehrere Minuten
pub get	löst die Abhängigkeiten laut pubspec.lock auf
pub upgrade	hebt Abhängigkeiten auf die neuesten erlaubten Versionen und schreibt pubspec.lock neu
build_runner	generiert Code (freezed, json_serializable …)
pod install	aktualisiert die iOS-Pods

Die Reihenfolge ist fest, egal in welcher Reihenfolge du die Häkchen setzt:

clean → pub get → pub upgrade → build_runner → pod install

clean muss vor pub get laufen, sonst wirft es die gerade aufgelösten Abhängigkeiten wieder weg.

pub upgrade als fester Pre-Step kostet Reproduzierbarkeit: Jeder Build schreibt pubspec.lock neu und baut womöglich gegen andere Paketversionen. Der Editor weist darauf hin. Für gelegentliche Updates gibt es den Knopf pub upgrade im Tab Build, siehe Versionen und Updates.

Live-Vorschau

Am unteren Rand des Editors steht immer die Kommandozeile bzw. das Script (aufgelöst), so wie es mit den aktuellen Feldern ausgeführt würde. Jede Änderung im Formular wirkt sofort auf die Vorschau. Mit dem Kopier-Symbol übernimmst du den Befehl in die Zwischenablage und kannst ihn im Terminal von Hand ausführen.

Dasselbe gilt im Tab Build: Unter Auszuführender Befehl bzw. Auszuführendes Script steht, was beim Klick auf Build starten tatsächlich läuft.

Prüfung und Trockenlauf

Unter Prüfung sammelt der Editor, was am Preset nicht stimmt oder auffällt, zum Beispiel:

• eine leere oder doppelte ID
• ein Dart-Define-Schlüssel mit =
• eine Datei unter --dart-define-from-file, die es nicht gibt
• ein IPA-Preset ohne ExportOptions.plist (Xcode fragt dann womöglich interaktiv nach)
• ein Output-Typ, der nicht zur Plattform passt
• pod install ohne ios/-Ordner
• ein eigenes Script ohne set -euo pipefail oder ohne Artefakt-Meldung

Der Knopf Trockenlauf prüft zusätzlich Pfade und Dateien, ohne etwas auszuführen. Das Ergebnis erscheint als eigener Abschnitt im Editor: entweder ohne Blocker oder mit der Liste dessen, was den Build verhindern würde.

Presets für mehrere Kunden

Liefert ihr eine App an mehrere Kunden, hat jeder Kunde ein eigenes Projekt mit eigenen Presets. Die Unterschiede liegen typischerweise in Flavor, Target, Dart-Defines und Store-IDs. Damit nicht jedes Preset von Hand entsteht:

• Duplizieren im Projekt-Editor kopiert ein Preset innerhalb des Projekts.
• Duplizieren im Kontextmenü der Projektliste kopiert ein ganzes Projekt samt Presets.
• Eine eingecheckte buildstation.json bringt die Presets auf den nächsten Mac, siehe Projekte anlegen.

Alle Kundenvarianten mit einem Klick bauen kannst du über Alle in die Warteschlange …, beschrieben unter Bauen und Warteschlange.