Pipeline behalten, Build-Mac wechseln

Diese Pipelines laufen bereits auf einem Cloud-Mac

Verlagern Sie Build- und Testschritte, die macOS benötigen, auf einen dedizierten physischen Mac mini. Native iOS-, Flutter-, Unity- und MLX-Workloads haben unterschiedliche Engpässe. Prüfen Sie zuerst Befehle und Voraussetzungen und wählen Sie dann anhand von Arbeitsspeicher, Cache und Parallelität den passenden Tarif. Hier finden Sie praxistaugliche Workflows statt Benchmark-Zahlen.

Dedizierter physischer Mac, keine VM. Tagesmiete ab $20.5/Tag; die aktuelle Verfügbarkeit sehen Sie direkt in der Konsole.

Workload auswählen

5 Workloads, alle aufgeklappt. Wählen Sie eine Kategorie, um die passenden Workloads hervorzuheben und anzusteuern. Die übrigen Inhalte bleiben sichtbar.

Von der Auslösung bis zur Abnahme

Finden Sie den passenden Build-Schritt.

Die folgenden Befehle werden auf dem Knoten ausgeführt. Installieren Sie zuerst die Projektabhängigkeiten und setzen Sie dann die passenden Umgebungsvariablen. Pfade müssen auf Ihr Projekt und Ihre Konfigurationsdateien verweisen. Beim Kopieren werden nur die Befehle kopiert, nicht ausgeführt.

Native iOS · Nightly Build

Git-Push startet das Archive; den Upload übernimmt fastlane.

Registrieren Sie den Cloud-Mac als selbst gehosteten Runner für GitHub Actions, als GitLab Runner oder als Jenkins Agent. Nach einem Push auf den Release-Branch checken Sie zunächst einen festen Commit aus und erstellen dann ein Release-Archive und eine IPA. Der TestFlight-Upload ist ein separater Schritt. So lassen sich Build- und Upload-Fehler unabhängig voneinander erneut ausführen.

Diese drei Dinge zuerst vorbereiten

  • Setzen Sie WORKSPACE und SCHEME und EXPORT_OPTIONS so, dass sie auf den Workspace, das Shared Scheme und die Exportkonfiguration verweisen.
  • Hinterlegen Sie das Signierzertifikat und das Provisioning-Profil für den aktuellen Build-Benutzer. Verwalten Sie sie bei Bedarf mit fastlane match und stellen Sie entschlüsselte Zugangsdaten über CI-Secrets bereit.
  • Setzen Sie ASC_API_KEY_JSON auf den Pfad zur JSON-Datei mit dem App Store Connect API-Schlüssel für fastlane. Speichern Sie den Schlüssel nicht im Code-Repository.

Das sollten Sie bei der Abnahme prüfen

das Archive unter build/App.xcarchive, die exportierte IPA, den Commit und die Xcode-Version. Prüfen Sie, ob TestFlight die entsprechende Version erhalten hat: Ein erfolgreicher Build-Befehl bedeutet nicht, dass der Upload abgeschlossen ist.

Warum dieser Tarif? Die 24 GB Unified Memory des Host M4 Plus eignen sich für tägliche Builds mit mehreren Targets. Bringen Sie den Ablauf zunächst seriell zum Laufen und erhöhen Sie die Parallelität erst, wenn Arbeitsspeicherdruck und DerivedData-Verbrauch dafür sprechen.

Archive → Export → Upload
set -euo pipefail
: "${WORKSPACE:?Set WORKSPACE}"
: "${SCHEME:?Set SCHEME}"
: "${EXPORT_OPTIONS:?Set EXPORT_OPTIONS}"
: "${ASC_API_KEY_JSON:?Set ASC_API_KEY_JSON}"

mkdir -p build
xcodebuild -version
xcodebuild \
  -workspace "$WORKSPACE" -scheme "$SCHEME" \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath build/App.xcarchive archive

xcodebuild -exportArchive \
  -archivePath build/App.xcarchive \
  -exportPath build/export \
  -exportOptionsPlist "$EXPORT_OPTIONS"

IPA_PATH="$(find build/export -type f -name '*.ipa' -print -quit)"
test -n "$IPA_PATH"
bundle exec fastlane pilot upload \
  --ipa "$IPA_PATH" \
  --api_key_path "$ASC_API_KEY_JSON"
Tarif: Host M4 Plus · M4 / 24 GB / 512 GB Empfohlener Knoten: Japan (Tokio)
Host M4 Plus mieten

Cross-Plattform · Flutter

Android bleibt auf Linux – migrieren Sie nur den iOS-Schritt.

Sie müssen nicht die gesamte Pipeline für beide Plattformen umziehen. Der Linux-Runner behält die Android-Aufgaben, der Cloud-Mac übernimmt CocoaPods, die Xcode-Kompilierung und den IPA-Export. Verwenden Sie auf beiden Seiten denselben Commit und führen Sie die Ergebnisse anschließend zusammen. Schlägt eine Seite fehl, führen Sie nur deren Job erneut aus.

Caches mit klaren Invalidierungsregeln

  • Fixieren Sie die Versionen von Flutter, Ruby, CocoaPods und Xcode. Behalten Sie pubspec.lock, Podfile.lock und Gemfile.lock bei.
  • Cachen Sie die Pub- und CocoaPods-Downloadverzeichnisse. Der Cache-Schlüssel sollte mindestens die Toolchain-Versionen und Prüfsummen der Lockfiles enthalten.
  • Lassen Sie parallele Jobs nicht in dasselbe Projektverzeichnis schreiben. Trennen Sie DerivedData und Ausgabeverzeichnisse pro Job, damit sich Caches nicht gegenseitig beeinträchtigen.

Das sollten Sie bei der Abnahme prüfen

Speichern Sie die signierte IPA aus build/ios/ipa sowie Build-Logs und Lockfiles. Prüfen Sie das Artefakt zuerst durch eine Installation auf einem Gerät oder in einem späteren Testjob, bevor Sie den Build als releasefähig markieren.

Warum dieser Tarif? Der Host M4 Lite ist ein guter Einstieg für einzelne Jobs. Wenn gleichzeitig Simulatoren laufen, Tests ausgeführt und Pakete erstellt werden, messen Sie zunächst den Spitzenverbrauch des Arbeitsspeichers. Ziehen Sie erst dann den Host M4 Plus in Betracht, statt sofort mehr Parallelität hinzuzufügen.

Flutter · iOS-Job
set -euo pipefail
: "${EXPORT_OPTIONS:?Set EXPORT_OPTIONS}"

flutter --version
xcodebuild -version
flutter doctor -v
bundle check || bundle install
flutter pub get

(
  cd ios
  bundle exec pod install --deployment
)

flutter build ipa \
  --release \
  --export-options-plist="$EXPORT_OPTIONS"

find build/ios/ipa -type f -name '*.ipa' -print
Tarif: Host M4 Lite · M4 / 16 GB / 256 GB Empfohlener Knoten: Singapur
Host M4 Lite mieten

Games · iOS-Paket

Unity-Projekt übernehmen, signieren, exportieren und Größe prüfen.

Die Unity-Ressourcenverarbeitung und die Xcode-Kompilierung sind zwei getrennte Schritte. Erzeugen Sie zuerst mit dem projektspezifischen Exportprozess ein Xcode-Projekt und führen Sie anschließend Archive und Export auf dem Cloud-Mac aus. Vergleichen Sie die Paketgröße mit identischen Ressourceneinstellungen, damit Sie Änderungen eindeutig Ressourcen, Build-Optionen oder dem Exportprozess zuordnen können.

Die Exportgrenze klar festlegen

  • UNITY_IOS_DIR muss auf das bereits exportierte iOS-Projektverzeichnis verweisen. Der folgende Befehl startet in der Xcode-Phase und ersetzt nicht das Unity-Build-Skript Ihres Projekts.
  • Wenn ein Plugin einen Workspace erzeugt hat, setzen Sie UNITY_WORKSPACE; andernfalls verwenden Sie Unity-iPhone.xcodeproj. Verwenden Sie nicht beide Einstiegspunkte gleichzeitig.
  • Bereiten Sie die Signierung und EXPORT_OPTIONS vor. Aktivieren Sie die entsprechende Berichtseinstellung in der Exportkonfiguration, wenn Sie einen App-Thinning-Bericht benötigen.

Das sollten Sie bei der Abnahme prüfen

Prüfen Sie die IPA-Dateigröße, die Export-Logs und Änderungen an den Ressourcen. Die komprimierte IPA-Größe entspricht nicht der tatsächlichen Download- oder Installationsgröße. Berücksichtigen Sie für die Release-Entscheidung auch den Exportbericht und die Verarbeitung durch den Vertriebskanal.

Warum dieser Tarif? Mit 64 GB Unified Memory und einer 2-TB-SSD eignet sich der Host M4 Pro für größere Projekte mit vielen Ressourcen und umfangreichen Archive-Caches. Protokollieren Sie zuerst den Verbrauch beim Import der Ressourcen, beim Kompilieren und beim Export, bevor Sie die Job-Warteschlange planen.

Unity-Export → Xcode
set -euo pipefail
: "${UNITY_IOS_DIR:?Set UNITY_IOS_DIR}"
: "${EXPORT_OPTIONS:?Set EXPORT_OPTIONS}"

mkdir -p build
if [ -n "${UNITY_WORKSPACE:-}" ]; then
  xcodebuild -workspace "$UNITY_WORKSPACE" \
    -scheme Unity-iPhone -configuration Release \
    -destination 'generic/platform=iOS' \
    -archivePath build/Game.xcarchive archive
else
  xcodebuild \
    -project "$UNITY_IOS_DIR/Unity-iPhone.xcodeproj" \
    -scheme Unity-iPhone -configuration Release \
    -destination 'generic/platform=iOS' \
    -archivePath build/Game.xcarchive archive
fi

xcodebuild -exportArchive \
  -archivePath build/Game.xcarchive \
  -exportPath build/game-export \
  -exportOptionsPlist "$EXPORT_OPTIONS"

find build/game-export -type f -name '*.ipa' \
  -exec du -h {} \;
Tarif: Host M4 Pro · M4 Pro / 64 GB / 2 TB Empfohlener Knoten: Südkorea (Seoul)
Host M4 Pro mieten

Native iOS · Kompatibilitätstests

Xcode-Version fixieren und die Simulator-Matrix systematisch durchlaufen.

Die Anpassung an ein neues Betriebssystem ist erst abgeschlossen, wenn mehr als nur der Build erfolgreich ist. Nehmen Sie zentrale Navigation, Berechtigungsdialoge, Dark Mode und wichtige Layouts in die Tests auf. Speichern Sie die Ergebnisse nach Xcode-Version und Simulator-Runtime. Machen Sie die Matrix zunächst seriell reproduzierbar und entscheiden Sie anschließend, welche Tests parallel laufen sollen.

Versionen und Geräte nachvollziehbar halten

  • Verwalten Sie mehrere Xcode-Versionen mit xcodes. Wählen Sie die Version für jeden Job über DEVELOPER_DIR aus, statt bei parallelen Jobs die systemweite Standard-Toolchain zu ändern.
  • Prüfen Sie zunächst, welche Simulatoren mit der aktuellen Xcode-Version verfügbar sind, und weisen Sie SIM_A und SIM_B die UDIDs verschiedener Geräte zu. Die Simulator-Runtimes müssen vor der Ausführung installiert sein.
  • Bewahren Sie .xcresult auf, statt nur die letzte Zeile des Terminals zu speichern. UI-Screenshots, fehlgeschlagene Tests und Wiederholungsprotokolle müssen demselben Commit zugeordnet werden können.

Das sollten Sie bei der Abnahme prüfen

Prüfen Sie für jedes Ziel separat den Test-Exitcode und das Ergebnis-Bundle. Simulator-Tests ersetzen keine Prüfungen auf echten Geräten für Peripherie, Leistung und Distribution. Planen Sie diese Aufgaben separat ein.

Warum dieser Tarif? Der Host M4 Plus ist ein guter Ausgangspunkt für tägliche Regressionstests. Wie viele Simulatoren gleichzeitig laufen können, hängt vom tatsächlichen Arbeitsspeicherdruck ab – 24 GB ermöglichen keine unbegrenzte Parallelität.

Xcode · Simulator-Matrix
set -euo pipefail
: "${DEVELOPER_DIR:?Set DEVELOPER_DIR}"
: "${WORKSPACE:?Set WORKSPACE}"
: "${SCHEME:?Set SCHEME}"
: "${SIM_A:?Set SIM_A}"
: "${SIM_B:?Set SIM_B}"
export DEVELOPER_DIR

mkdir -p build
xcodebuild -version
xcrun simctl list devices available

RUN_ID="$(date +%s)-$$"
for DEVICE_ID in "$SIM_A" "$SIM_B"; do
  xcodebuild test \
    -workspace "$WORKSPACE" \
    -scheme "$SCHEME" \
    -destination "platform=iOS Simulator,id=$DEVICE_ID" \
    -parallel-testing-enabled NO \
    -resultBundlePath \
      "build/$RUN_ID-$DEVICE_ID.xcresult"
done
Tarif: Host M4 Plus · M4 / 24 GB / 512 GB Empfohlener Knoten: Hongkong
Host M4 Plus mieten

KI · MLX-Inferenztests

Modell im Unified Memory ausführen: zuerst Stabilität prüfen.

Laden Sie auf einem physischen Apple-Silicon-Knoten mit MLX ein kompatibles Modell und protokollieren Sie Generierungsgeschwindigkeit, Spitzenverbrauch des Arbeitsspeichers und Kontextlänge. Testen Sie zunächst eine einzelne Anfrage und anschließend Batch-Verarbeitung. Build-Jobs und Inferenztests teilen sich die Ressourcen desselben Rechners – setzen Sie nicht beide ohne vorherige Messung voll aus.

Modell- und Ressourcengrenzen zuerst klären

  • MODEL_DIR muss auf das vorbereitete Verzeichnis eines MLX-kompatiblen Modells verweisen. Prüfen Sie Modellherkunft, Lizenz, Quantisierungsformat und Abhängigkeitsversionen.
  • Die 64 GB Unified Memory stehen dem gesamten Rechner zur Verfügung. Betriebssystem, Modellgewichte, Cache und weitere Prozesse beanspruchen ebenfalls Speicher. Ob das Modell geladen werden kann, hängt von Modell und Kontextkonfiguration ab.
  • Verwenden Sie feste Prompts und eine festgelegte Ausgabelänge. Protokollieren Sie Kaltstart und Folgeanfragen separat. Rechnen Sie die Modelldownloadzeit nicht in den Inferenzdurchsatz ein.

Das sollten Sie bei der Abnahme prüfen

Bewahren Sie Modellversion, Quantisierungskonfiguration, MLX-Umgebung und Ausführungslogs auf. Verwenden Sie /usr/bin/time -l zur Beobachtung des Prozessverbrauchs und prüfen Sie anhand der systemweiten Speicherbelastung, ob Speicher ausgelagert wird.

Warum dieser Tarif? Die 64 GB Unified Memory des Host M4 Pro eignen sich für Experimente mit höherem Speicherbedarf. Die 2-TB-SSD bietet Platz für Modelldateien und Versuchsergebnisse, vergrößert aber nicht den für das Modell verfügbaren Arbeitsspeicher.

MLX · Lokale Inferenz
set -euo pipefail
: "${MODEL_DIR:?Set MODEL_DIR}"

python3 -m venv .venv
. .venv/bin/activate
python -m pip install mlx-lm
mkdir -p build

python -m pip freeze > build/mlx-environment.txt
/usr/bin/time -l \
  python -m mlx_lm.generate \
    --model "$MODEL_DIR" \
    --prompt "Explain reproducible builds." \
    --max-tokens 128 \
    > build/mlx-output.txt \
    2> build/mlx-metrics.txt

cat build/mlx-output.txt
cat build/mlx-metrics.txt
Tarif: Host M4 Pro · M4 Pro / 64 GB / 2 TB Empfohlener Knoten: US-Westküste
Host M4 Pro mieten

Prüfen Sie nach dem Kopieren der Befehle Variablen und Signierkonfiguration in Ihrem Projektverzeichnis, bevor Sie sie ausführen.

Empfehlungen sind keine Leistungsversprechen

Konfiguration mit einem vollständigen Job abstimmen

Die Knotenempfehlungen orientieren sich an den Zeitzonen der Zusammenarbeit und beruhen nicht auf gemessenen Netzwerk-Latenzen. Auch die Standorte Ihres Code-Repositorys, der Artefaktspeicherung und der Teammitglieder beeinflussen die Nutzung.

01

Ressourcenspitzen erfassen

Fixieren Sie Commit und Abhängigkeitsversionen und führen Sie einen vollständigen Job aus. Erfassen Sie Arbeitsspeicherdruck, Cache- und Artefaktgröße separat, statt den Tarif allein anhand einer einzelnen Build-Zeit auszuwählen.

02

Warteschlange und Ausführung trennen

Beginnen Sie mit einem einzelnen Runner. Erhöhen Sie die Parallelität erst, wenn der Job stabil läuft. Erfassen Sie Wartezeit auf den Runner, Downloadzeit der Abhängigkeiten und Kompilierzeit separat.

03

Knoten nahe an Ihren Arbeitswegen wählen

Zur Auswahl stehen Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und die US-Westküste – insgesamt 5 Knoten. Testen Sie zunächst Projektsynchronisierung und interaktive Verbindungen und legen Sie dann den Ausführungsstandort für Ihr Team fest.

Abnahmekriterien klar festlegen

Was möchten Sie morgen früh vorfinden?

Die folgenden Szenarien beschreiben Nutzungsziele für drei Rollen, keine Kundenbewertungen oder Messergebnisse. Wenn Sie diese Ziele in die Pipeline-Abnahme aufnehmen, bringt das mehr als die Jagd nach einem schnelleren Einzelbuild.

„Morgens möchte ich das Archive, die Testergebnisse und die Fehlerprotokolle zum richtigen Commit vorfinden, statt zuerst nach dem Build-Rechner im Büro sehen zu müssen.“
iOS-Verantwortliche:r · Ziel für Nightly Builds
„Ich migriere nur den iOS-Teil der Flutter-Pipeline. Beide Plattformen verwenden denselben Commit, und bei einem Fehler kann ich den jeweiligen Job separat wiederholen, statt die gesamte Pipeline neu aufzusetzen.“
Mobile-Architekt:in · Ziel für die Pipeline-Aufteilung
„Ich möchte Modellversion, Speicherverbrauch und Generierungsergebnis gemeinsam speichern. So bleibt das Experiment reproduzierbar und ich kann den nächsten Rechner auf einer verlässlichen Grundlage auswählen.“
ML Engineer · Ziel für Inferenztests

Erst den Build-Schritt auswählen, dann den Rechner.

Für einzelne Jobs eignet sich der Host M4 Lite, für mehrere Targets und tägliche Regressionstests der Host M4 Plus und für große Projekte sowie speicherintensive Experimente der Host M4 Pro. Vergleichen Sie auf der Tarifseite die drei Konfigurationen, vier Mietlaufzeiten und Zusatzoptionen und schließen Sie anschließend die Bestellung ab.

Abrechnung ausschließlich in US-Dollar. Unterstützte Zahlungsmethoden: USDT-TRC20 sowie Visa, Mastercard und Amex über Stripe. Welche Zahlungswege verfügbar sind, hängt von der Rückmeldung des Backend-Systems ab.