Checkliste für den Build-Tag

Der Code ist fertig –
was kommt als Nächstes auf dem Mac?

Entwickeln Sie lokal weiter unter Windows oder Linux und übertragen Sie das Projekt erst zum Archivieren auf einen Cloud-Mac. Prüfen Sie zuerst Verbindung und Umgebung, stellen Sie dann die Abhängigkeiten wieder her und importieren Sie Ihre Signierungsdaten. Erstellen Sie anschließend mit Ihrem Framework den iOS-Build.

Hier geht es um Verbindung, browserbasierten Remote-Desktop, Einrichtung und Abrechnung. Wir schreiben keinen Anwendungscode, verwalten keine Apple-Entwicklerkonten und übernehmen weder die Prüfung der Vertriebsberechtigung noch die Signierungsfreigabe.

Sie haben bereits einen Mac gemietet? Beginnen Sie mit der folgenden Umzugs-Checkliste. Verbindungsdaten und Instanzstatus finden Sie nur im angemeldeten Kontrollzentrum.

Beim Umzug getrennt vorgehen

Projektdaten, Toolchain und CI folgen jeweils einem eigenen Weg.

Lokale Mac- und Windows-Projekte lassen sich aus einem Versionsverwaltungssystem wiederherstellen. Übertragen Sie zuerst reproduzierbare Konfigurationen und dann vertrauliche Daten. Kopieren Sie nicht einfach den gesamten Cache-Ordner des alten Rechners.

Datenübergabe

Projekt und Signierungsdaten übernehmen

Klonen Sie das Projekt aus einem Git-Repository, auf das Sie zugreifen dürfen. Geben Sie die Repository-Adresse über eine Umgebungsvariable an und schreiben Sie Zugriffstoken weder in den Befehlsverlauf noch in Screenshots.

  1. Synchronisieren Sie Branches und Submodule und behalten Sie die Sperrdateien von Framework und Paketmanager bei.
  2. Wenn Signierung erforderlich ist, übertragen Sie Zertifikat und Provisioning-Profil über einen kontrollierten Kanal. Importieren Sie nur die für diesen Auftrag erforderlichen Daten.
  3. Übertragen Sie große Dateien bevorzugt per SSH, sofern der Zugang aktiviert und erreichbar ist. Ob der Browser-Desktop Datei-Uploads unterstützt, hängt von der jeweiligen Verbindung ab.
git clone "$PROJECT_REPOSITORY" project
cd project
git submodule update --init --recursive
git rev-parse HEAD
git status --short

Prüfen: Auf beiden Rechnern muss derselbe Commit vorliegen. Zugriffsrechte für private Abhängigkeiten, zusätzliche Ressourcen und Signierungsdateien werden nicht automatisch mit dem Code wiederhergestellt.

Umgebung einrichten

Erst Versionen prüfen, dann Abhängigkeiten ergänzen

Prüfen Sie zunächst, welche Tools auf der Instanz tatsächlich verfügbar sind. Gehen Sie nicht davon aus, dass jede Maschine dieselben Versionen vorinstalliert hat. Stimmen Xcode und Projektanforderungen nicht überein, klären Sie zuerst die Kompatibilität.

  1. Prüfen Sie Entwicklerverzeichnis, Version und verfügbare SDKs von Xcode. Vergewissern Sie sich, dass die Kommandozeile auf die gewünschte Toolchain zeigt.
  2. Stellen Sie die benötigten Tools mit Homebrew und Brewfile wieder her und prüfen Sie anschließend CocoaPods, Flutter SDK und Node.
  3. Verwenden Sie für Unity-Projekte die passende Editor-Version und prüfen Sie in Unity Hub, ob iOS Build Support verfügbar ist.
xcode-select -p
xcodebuild -version
xcodebuild -showsdks
brew --version
brew bundle check
pod --version
flutter --version
node --version

Prüfen: Führen Sie die Prüfung mit Brewfile nur in dessen Verzeichnis aus. Fehlt ein Befehl, installieren Sie zunächst das entsprechende Tool. Die Unity-Nutzungslizenz müssen Sie selbst prüfen.

Automatisierung einrichten

Erst lokal erfolgreich bauen, dann CI einrichten

Führen Sie zunächst in einer interaktiven Sitzung einen Build aus und prüfen Sie, ob Abhängigkeiten und Signierung funktionieren. Registrieren Sie erst danach einen temporären self-hosted Runner, damit Umgebungsfehler nicht mit Problemen in der Pipeline verwechselt werden.

  1. Laden Sie bei Ihrer CI-Plattform ein Runner-Paket herunter, das zu macOS und der Prozessorarchitektur passt, und verwenden Sie ein kurzlebiges Registrierungstoken.
  2. Registrieren Sie den Runner im entpackten Verzeichnis gemäß der Plattformdokumentation. Prüfen Sie Job-Tags, Arbeitsverzeichnis und ausführenden Benutzer.
  3. Falls das Projekt bereits eine fastlane-Konfiguration enthält, listen Sie zunächst die Lanes auf und führen Sie dann den im Team vereinbarten Build-Ablauf aus.
./config.sh --url "$CI_REPOSITORY_URL" --token "$RUNNER_TOKEN"
./run.sh

bundle check
bundle exec fastlane lanes

Prüfen: Die Runner-Befehle hängen von der CI-Plattform ab und sind kein universelles Installationsprogramm. Die gezeigte Registrierung gilt nur für Plattformen mit den entsprechenden Skripten. Deregistrieren Sie den Runner und widerrufen Sie das Token vor Ablauf.

Dateiübertragung funktioniert nicht automatisch, nur weil der Remote-Desktop geöffnet ist.Welche Inhalte die Zwischenablage überträgt, welche Größen möglich sind und ob Dateiübertragungen unterstützt werden, hängt von der jeweiligen Verbindung ab. Wenn Sie einen SSH- oder VNC-Client benötigen, prüfen Sie im Kontrollzentrum die Zugangsmethode, Zugangsdaten und Verbindungsadresse. Gehen Sie nicht davon aus, dass ein Port geöffnet ist. Legen Sie vertrauliche Daten weder auf öffentlichen Download-Seiten ab noch fügen Sie sie einem Support-Ticket bei.

Weiter mit Ihrem Projekttyp

Drei Wege zum iOS-Build – und mehr als nur die Meldung „Build erfolgreich“.

Stellen Sie die Umgebung zunächst mit den im Projekt festgelegten Versionen wieder her und kümmern Sie sich dann um Plattformabhängigkeiten und Signierung. Führen Sie die folgenden Befehle im jeweiligen Projektverzeichnis aus. Ob sich die Artefakte verteilen lassen, hängt außerdem von Signierung, Vertriebsberechtigung und den Anforderungen der Zielplattform ab.

Flutter: Archiv und IPA aus dem Projekt erstellen

Voraussetzungen:Flutter SDK und Projektanforderungen müssen zusammenpassen. iOS-Projekt, Plugin-Abhängigkeiten und Xcode-Toolchain müssen verfügbar sein; Signierungsdaten und App-Kennung müssen übereinstimmen.

flutter doctor -v
flutter pub get
flutter build ipa

Beheben Sie zuerst flutter doctor -v gemeldete Probleme mit der iOS-Toolchain. Schlägt die Wiederherstellung der Abhängigkeiten fehl, unterscheiden Sie zwischen Netzwerkproblemen, Versionskonflikten und fehlenden Zugriffsrechten auf private Pakete. Wiederholen Sie den Archivierungsbefehl nicht, um Fehler bei den Voraussetzungen zu überdecken.

Erwartetes Ergebnis:Prüfen Sie nach erfolgreichem Build build/ios/archive auf das Archiv und build/ios/ipa auf die exportierten Dateien. Verzeichnisstruktur und Exportverhalten hängen von der verwendeten Flutter-Version und der Build-Ausgabe ab.

Wenn nur ein Archiv, aber keine IPA vorliegt, prüfen Sie die Export- und Signierungsfehler. Ein erfolgreicher Build lädt das Installationspaket nicht automatisch zu TestFlight hoch.

React Native: mit dem richtigen Workspace archivieren

Voraussetzungen:Node, Paketmanager und Projektsperrdatei müssen zusammenpassen. Bei Projekten mit CocoaPods müssen die iOS-Abhängigkeiten installiert sein. Prüfen Sie außerdem, ob Sie das richtige Scheme verwenden.

node --version
bundle check
cd ios
bundle exec pod install
open .

Gibt es eine Gemfile, verwenden Sie die im Projekt festgelegte Bundler-Umgebung. Projekte ohne Bundler installieren Abhängigkeiten nach dem Teamablauf. Öffnen Sie in Xcode den erstellten .xcworkspaceund nicht versehentlich die Projektdatei ohne Pods-Abhängigkeiten.

Erwartetes Ergebnis:Wählen Sie das gewünschte Scheme und ein passendes Geräte-Archivierungsziel. Erstellen Sie über Product → Archive ein .xcarchiveund exportieren oder laden Sie es anschließend im Organizer gemäß dem Vertriebsweg hoch.

Ein erfolgreicher Simulatorlauf bedeutet nicht, dass sich ein Gerätearchiv erstellen lässt. Bei Fehlern in nativen Modulen sichern Sie den ersten Compilerfehler und die betreffenden Abhängigkeitsversionen – nicht nur die letzte Zeile der Fehlermeldung.

Unity: Nach dem Export geht es in Xcode weiter

Voraussetzungen:Die Unity-Editor-Version muss zum Projekt passen. Das iOS-Modul muss verfügbar sein, native Plugins und Ressourcen müssen vollständig vorliegen und die passende Editor-Lizenz muss vorhanden sein.

xcodebuild -version
xcodebuild -list -project "$EXPORTED_XCODE_PROJECT"

Wechseln Sie in Unity zum iOS-Buildziel und exportieren Sie das Xcode-Projekt. Bei Projekten mit IL2CPP muss der generierte Code nativ kompiliert werden. Der Export allein ergibt noch kein verteilbares Installationspaket.

Erwartetes Ergebnis:Bearbeiten Sie Signierung, Abhängigkeiten und Zieleinstellungen in Xcode und führen Sie Archive aus. Exportieren Sie anschließend die IPA oder laden Sie sie gemäß dem Vertriebsablauf hoch. Hat ein Plugin einen Workspace erstellt, öffnen Sie diesen für die weitere Bearbeitung.

Planen Sie bei großen Projekten genügend Arbeitsspeicher und Platz für temporäre Dateien ein. Apple Silicon M4 Pro / 64GB RAM / 2TB SSD ist im Katalog eine Option für große Projekte, garantiert aber keine bestimmte Build-Zeit.

Nach dem ersten erfolgreichen Build auch die Reproduzierbarkeit sichern.

Notieren Sie Commit, Xcode- und Framework-Versionen, Abhängigkeitssperrdateien, verwendetes Scheme, Build-Befehl und Speicherort der Artefakte. Nehmen Sie veröffentlichbare Konfigurationen in die Versionsverwaltung auf und bewahren Sie private Schlüssel sowie Zugriffstoken separat auf. Wenn Sie das nächste Mal tageweise einen Mac mieten, stellen Sie diese Umgebung anhand der Notizen wieder her, statt sie von Grund auf neu zu erraten.

Desktop- und Build-Probleme unterscheiden

Ruckelt das Bild, prüfen Sie zuerst die Verbindung. Hängt das Archivieren, sehen Sie zuerst ins Protokoll.

Verzögerte Mausbewegungen und langsame Bildaktualisierung deuten meist auf Netzwerk- oder Anzeigeeinstellungen hin. Reagiert die Maus normal, während der Build lange läuft, prüfen Sie Build-Protokoll und Ressourcenauslastung. Ein anderer Remote-Zugangsweg behebt keine Projektfehler.

  1. 01

    Knoten und Netzwerk prüfen

    Prüfen Sie zuerst, ob der aktuelle Knoten in der Nähe Ihres Zugangsstandorts liegt. Vergleichen Sie anschließend kabelgebundene und stabile WLAN-Verbindungen und pausieren Sie Synchronisierungen, die den Upload auslasten. Wenn Sie einen anderen Knoten wählen möchten, lesen Sie zunächst den nächsten Abschnitt. Ein Knotenwechsel bedeutet nicht, dass sich ein bestehender Auftrag sofort und ohne Datenverlust übertragen lässt.

    Zu beachten: Die geografische Nähe ist nur ein erster Anhaltspunkt. Routing des Anbieters, Verbindungen zwischen Regionen und lokale Netzüberlastung beeinflussen weiterhin die tatsächliche Round-Trip-Latenz.

  2. 02

    Anzeige entlasten

    Reduzieren Sie die Bildqualität, Auflösung oder Bildrate in den verfügbaren Einstellungen der aktuellen Remote-Verbindung und deaktivieren Sie unnötige Animationen. Ändern Sie jeweils nur eine Einstellung und notieren Sie die Auswirkungen.

    Zu beachten: Dadurch können Codierungs- und Übertragungslast sinken. Die physische Round-Trip-Zeit im Netzwerk wird dadurch nicht kürzer, und CPU-intensive Builds werden nicht schneller.

  3. 03

    VNC-Client vergleichen

    Wenn das Kontrollzentrum die nötigen Verbindungsdaten bereitstellt, können Sie mit einem VNC-Client die Bedienung derselben Instanz vergleichen. Der Browserzugriff eignet sich für den direkten Desktop-Zugang; ein Client ist eine Alternative, um Unterschiede bei der Verbindungsimplementierung einzugrenzen.

    Zu beachten: Ein Client kann andere Anzeige- und Zwischenablageoptionen bieten, ändert aber nicht den Standort des Knotens. Dateiübertragungen hängen weiterhin von der Implementierung auf beiden Seiten ab; eine allgemeine Unterstützung können wir nicht zusichern.

  4. 04

    Fehler nachvollziehbar dokumentieren

    Notieren Sie bei Verbindungsfehlern den Hinweis auf der Seite, Zeitpunkt und Zeitzone. Bei fehlgeschlagenen Builds sichern Sie den ersten aussagekräftigen Fehler, den ausgeführten Befehl und die Versionsangaben. Decken Sie vor einem Screenshot Passwörter, Token, Zertifikatsdetails und private Projektinhalte ab.

    Zu beachten: Screenshots können bei der Diagnose helfen, ersetzen aber keinen kopierbaren Fehlertext. Melden Sie nicht nur „sehr langsam“ oder „Build fehlgeschlagen“, sondern geben Sie auch die Schritte zur Reproduktion an.

Die Knotenübersicht dient als Orientierung und zeigt keine Messwerte Ihrer konkreten Verbindung.

Hier sind alle 5 Knoten aufgeführt. Die Bereiche beziehen sich auf die angegebenen Versorgungsregionen und sind keine Latenzgarantie für beliebige Städte.

Knoten → Versorgungsregion → Richtwert für die Round-Trip-Latenz
KnotenVersorgungsregionRichtwert für Round-Trip-Latenz
SingapurSüdostasien20~50ms
TokioOstasien30~60ms
SeoulNordostasien30~50ms
HongkongSüdchina und Südostasien20~40ms
US-OstküsteOst-Nordamerika und Westeuropa25~35ms

Die Bereiche sind Richtwerte; maßgeblich ist Ihre tatsächliche Verbindung. Für interaktive Desktop-Arbeit empfiehlt sich ein Knoten in Ihrer Nähe. Bei Builds und beim Herunterladen von Artefakten sollten Sie außerdem Abhängigkeiten und Dateiübertragung berücksichtigen.

Auftrag vor dem Umzug prüfen

Vor einem Knotenwechsel: Projekt und Mietvertrag getrennt betrachten.

Der Knoten ist Teil der Auftragskonfiguration. Ein Wechsel zwischen Knoten innerhalb desselben Auftrags ist nicht standardmäßig vorgesehen. Wir garantieren nicht, dass Festplatte, Verbindungsadresse oder verbleibende Mietzeit automatisch übertragen werden. Ob eine Anpassung möglich ist und wie Kosten und Daten behandelt werden, muss anhand Ihres konkreten Auftrags über ein Support-Ticket im Kontrollzentrum geprüft werden.

Erst nachfragen, dann die bestehende Instanz ändern

Nennen Sie Auftragsnummer, aktuellen und gewünschten Knoten sowie den Grund. Geben Sie an, ob noch Builds laufen. Warten Sie auf die Bestätigung, wie der Auftrag angepasst werden kann, welche Kosten anfallen und welche Schritte nötig sind. Löschen Sie die Umgebung nicht und gehen Sie nicht davon aus, dass eine neue Instanz den Zustand der alten übernimmt, bevor dies bestätigt wurde.

Wenn Sie stattdessen einen weiteren Mac mieten möchten, prüfen Sie zuerst Konfiguration, Laufzeit und aktuelle Verfügbarkeit des neuen Auftrags. Für den alten Auftrag gelten beim Beenden oder Verlängern weiterhin die jeweiligen Auftrags- und Servicebedingungen.

Behandeln Sie die neue Instanz wie einen neuen Mac

Übertragen Sie nicht gesicherten Code und exportieren Sie Build-Artefakte. Sichern Sie erforderliche Konfigurationen, Zertifikate und Provisioning-Profile separat. Prüfen Sie auf der neuen Instanz Tool-Versionen, Zugriffsrechte und Signierung erneut. Gehen Sie nicht davon aus, dass Inhalte der alten Festplatte bereits übertragen wurden.

Aktualisieren Sie nach dem Wechsel die CI-Verbindungseinstellungen, deregistrieren Sie den alten Runner und widerrufen Sie nicht mehr benötigte Token. Für den Umgang mit Daten nach Ablauf gelten die Servicebedingungen und Hinweise im Kontrollzentrum. Eine Wiederherstellung nach Ablauf ist kein Ersatz für ein Backup.

Das erste Support-Ticket nachvollziehbar machen

Geben Sie klar an, auf welcher Maschine und bei welchem Schritt das Problem auftritt.

Melden Sie sich im Kontrollzentrum an, erstellen Sie über den Ticketbereich eine Anfrage und verknüpfen Sie den zu prüfenden Auftrag. Support-Tickets im Kontrollzentrum eignen sich für Fragen zu Instanzen, Verbindungen, Einrichtung und Abrechnung. Falls Sie sich nicht anmelden können, erreichen Sie uns unter support@testmini.com .

Vor dem Absenden diese Angaben sammeln

  • Auftrag und Knoten:Auftragsnummer, Modell, aktueller Knoten und betroffene Instanz.
  • Zeitpunkt und Umgebung:Zeitpunkt und Zeitzone, lokales Betriebssystem sowie Version von Browser oder VNC-Client.
  • Schritte und Ergebnis:Mit welcher Seite oder welchem Befehl Sie begonnen haben, was passieren sollte und was tatsächlich zu sehen war.
  • Fehler und Nachweise:Fehlertext, bereinigte Screenshots, relevante Protokollauszüge und Angabe, ob sich der Fehler wiederholen lässt.
  • Bereits ausprobiert:Ergebnisse von Maßnahmen wie Netzwerkwechsel, Anpassung der Bildqualität oder erneutem Verbindungsaufbau.

Bei Zahlungsfragen nennen Sie Auftragsnummer, Zahlungsmethode und den im Kontrollzentrum angezeigten Status. Für USDT-TRC20 können Sie den Transaktions-Hash angeben. Senden Sie bei Problemen mit einer Bankkarte weder die vollständige Kartennummer noch Sicherheitscode oder Bestätigungscode.

Den Tickettext in dieser Reihenfolge aufbauen

Tragen Sie die folgenden Angaben in das Ticket im Kontrollzentrum ein. Das gesamte Projekt müssen Sie nicht hochladen.

Betroffenes Objekt
Auftragsnummer, Knoten, Modell
Zeitpunkt
Genaue Uhrzeit und verwendete Zeitzone
Schritte zur Reproduktion
Reihenfolge der Aktionen, Befehle, Fehlertext
Umgebung
Browser-, Xcode- und Framework-Version
Bisherige Diagnose
Bereits ausprobierte Schritte und ihre Auswirkungen

Fügen Sie keine Anmeldepasswörter, privaten Schlüssel, Originalzertifikate oder CI-Registrierungstoken bei. Falls der Support weitere Diagnosedaten benötigt, stellen Sie nur die erforderlichen Mindestangaben gemäß den Ticket-Hinweisen bereit.

Den Bearbeitungsstand sehen Sie im Ticket. Eine Anfrage bedeutet nicht, dass das Problem bereits behoben ist.

Der Support arbeitet überwiegend während der Arbeitszeiten in der Asien-Pazifik-Region. Eine Bearbeitung innerhalb einer festen Zahl von Minuten oder Stunden können wir nicht zusichern. Antworten und weitere Fortschritte sehen Sie im Kontrollzentrum. Ergänzen Sie Angaben bitte im selben Ticket und halten Sie die Umgebung bereit, in der sich das Problem reproduzieren lässt. Läuft die Mietzeit bald ab, exportieren Sie zuerst wichtige Dateien und klären Sie dann eine Verlängerung.

Die Abrechnungsprüfung umfasst USDT-TRC20 und Visa / Mastercard / Amex über Stripe; abgerechnet wird in US-Dollar. Welche Zahlungswege tatsächlich verfügbar sind, richtet sich nach der Rückmeldung des Zahlungs-Gateways. Die Bestätigung kann von der Blockchain-Bestätigung oder der Bearbeitung durch den Kartenaussteller abhängen. Ein Screenshot allein bestätigt keine Zahlung.

Servicebedingungen weiter prüfen

Neben den technischen Schritten auch Mietzeit und Knoten klären.

Verbindung, Build und Auftrag sind unterschiedliche Problemfelder. Prüfen Sie die Voraussetzungen in der passenden Dokumentation und entscheiden Sie dann, ob Sie weiter diagnostizieren, ein Support-Ticket einreichen oder eine weitere Maschine mieten möchten.

Problem prüfen

Erfahren Sie mehr über die Mindestmietdauer von einem Tag, Unterschiede zwischen Browser und VNC, Abrechnung von Zusatzkäufen, Signierungsdaten und den Umgang mit Daten nach Mietende.

Häufige Fragen anzeigen

Knoten auswählen

Vergleichen Sie alle 5 Knoten anhand Ihrer Region und Arbeitsweise. Die Latenzwerte helfen bei der Auswahl, das tatsächliche Nutzungserlebnis hängt jedoch auch von Ihrer Verbindung ab.

Knotenauswahl prüfen

Servicebedingungen lesen

Prüfen Sie vor einem langen Build Abrechnungszeitraum, Verlängerung, Ablauf und Nutzungsgrenzen. Exportieren Sie unersetzliche Dateien rechtzeitig.

Servicebedingungen lesen

Umgebung vor dem Build prüfen, bei Problemen die Details mitliefern.

Wenn Sie bereits einen Auftrag haben, erledigen Sie den nächsten Schritt im Kontrollzentrum. Falls Sie noch keinen Mac gemietet haben, wählen Sie Konfiguration und Knoten passend zu Ihrem Projekt. Sichern Sie Ihre Projekte und Build-Artefakte selbst; Instanz- und Auftragsprobleme können Sie über ein Support-Ticket prüfen lassen.