Wählen Sie zuerst den passenden Arbeitsablauf, dann den Standort. Beide Modelle sind überall verfügbar. Jede Bestellung umfasst einen exklusiven physischen Apple-Silicon-Mac – keine virtuelle Maschine.
Ab $21.2 pro Tag. Die aktuelle Verfügbarkeit sehen Sie in Echtzeit in der Konsole.
Für grafische Arbeit zählt vor allem der Standort der Nutzer. Bei unbeaufsichtigten Builds sollten Sie auch Repository, Paketquellen und Ziel für Build-Artefakte berücksichtigen. Die folgenden Hinweise grenzen die Auswahl ein, sie sind kein Ranking gemessener Latenzzeiten.
Geeignet für Entwickler und CI-Teams mit Schwerpunkt in Südostasien. Wenn Sie häufig mit der grafischen Oberfläche arbeiten, testen Sie zuerst die Interaktion über Ihr lokales Netzwerk.
Prüfen Sie vor allem: VNC-Bedienung, Paket-Downloads und Rückübertragung von Build-Artefakten.
Standort Singapur wählenGeeignet für App-Teams mit Schwerpunkt in Japan und Entwickler, die Xcode-Projekte aus der Ferne prüfen müssen. Beziehen Sie bei der ersten Prüfung auch Teammitglieder ein, die regelmäßig mit der Oberfläche arbeiten.
Prüfen Sie vor allem: Reaktionszeit der Oberfläche, Repository-Zugriff und Uploads zur Verteilung.
Standort Tokio wählenGeeignet für Ingenieure und Mobile-Teams, die hauptsächlich in Südkorea arbeiten. Wenn Build-Abhängigkeiten und Code-Dienste ebenfalls in der Nähe des Teams liegen, prüfen Sie die Laufzeit der gesamten Pipeline.
Prüfen Sie vor allem: Codesynchronisierung, Wiederherstellung des Caches und Remote-Fehlerbehebung.
Standort Seoul wählenEine Option für Teams aus Südchina und Südostasien. Die Verbindung über verschiedene Netzwerke hängt von der tatsächlichen Route ab. Testen Sie daher über das Büronetzwerk, das Sie im Alltag nutzen.
Prüfen Sie vor allem: Büroverbindung, SSH-Zugriff und Dateiübertragung.
Standort Hongkong wählenGeeignet für Teams im Osten Nordamerikas und eine mögliche Option für Teams in Westeuropa. In Kombination mit Standorten in Asien-Pazifik lassen sich Build-Warteschlangen anhand von Arbeitszeiten und Job-Tags aufteilen.
Prüfen Sie vor allem: Repository-Zugriff, Upload von Build-Artefakten und Übergaben über Zeitzonen hinweg.
Standort im Osten der USA wählenDie Kürzel dienen zur Kennzeichnung der Standorte. Maßgeblich für Bestellung und Verfügbarkeit sind die Angaben, die die Konsole in Echtzeit anzeigt.
Der Standort bestimmt den Einsatzort, das Modell die Rechen- und Speicherressourcen. Die Tabelle zeigt, welche Modelle im Angebot sind – nicht die aktuelle Verfügbarkeit oder eine garantierte Bereitstellungszeit.
| Modell und Ausstattung | Singapur SG |
Tokio, Japan TYO |
Seoul, Südkorea SEL |
Hongkong HKG |
Osten der USA USE |
|---|---|---|---|---|---|
| Arm Line M4M4 / 16GB / 256GB | Im Angebot | Im Angebot | Im Angebot | Im Angebot | Im Angebot |
| Arm Grid M4 ProM4 Pro / 64GB / 2TB | Im Angebot | Im Angebot | Im Angebot | Im Angebot | Im Angebot |
Beide Modelle können an allen fünf Standorten eingesetzt werden. Prüfen Sie vor der Bestellung in der Konsole Modell, Standort, Abrechnungszeitraum und Gesamtbetrag. Der Status „Im Angebot“ in der Tabelle ist keine Zusage für eine feste Bereitstellungszeit.
Ein Build durchläuft Code, Abhängigkeiten, Kompilierung und Upload. Die geografische Entfernung erklärt nur einen Teil der Laufzeit. Aussagekräftige Ergebnisse erhalten Sie, wenn Sie dasselbe Projekt mit denselben Befehlen vergleichen.
Wenn Sie Projekte häufig per VNC bearbeiten, Oberflächen prüfen oder Signaturprobleme untersuchen, testen Sie zuerst die Verbindung zwischen Nutzer und Standort. Verwenden Sie dafür das übliche Büronetzwerk und testen Sie während der tatsächlichen Arbeitszeiten des Teams.
Halten Sie Eingabereaktion, Fensterbewegungen und Dateiübertragungen fest. Eine funktionierende SSH-Verbindung bestätigt nur den Zugriff über die Befehlszeile – sie ersetzt keinen Test der grafischen Oberfläche.
Wenn Sie zu App Store Connect hochladen, messen Sie die Upload-Phase separat. Der Standort des Build-Rechners sagt nichts über die tatsächliche Route zum Empfangsdienst aus. Die Region allein verrät nicht, welche Verbindung schneller ist.
Vergleichen Sie Upload, Wiederholungsversuche und Verarbeitung anhand desselben gültigen Build-Artefakts. Trennen Sie Kompilierungszeit, Netzwerkübertragung und Wartezeit auf die Verarbeitung beim Dienst, statt sie als einen Wert zu erfassen.
Ein dauerhaft eingesetzter CI-Runner muss regelmäßig Code, Paketabhängigkeiten und Cache abrufen. Prüfen Sie zuerst den Zugriff auf Git-Repository, private Paketquellen und Artefaktspeicher – und wählen Sie danach den Standort.
Führen Sie je einen Build mit kaltem und warmem Cache aus. Halten Sie Commit, Xcode-Version und Build-Parameter gleich. Testen Sie nach einem Standortwechsel erneut und werten Sie einen einzelnen Download nicht als dauerhafte Leistungszusage.
Beispiel: je ein Runner in Singapur und im Osten der USA. Das sind zwei unabhängige physische Rechner mit jeweils eigener Ausführungsumgebung – kein Cluster mit automatisch gemeinsamem Arbeitsspeicher oder Datenträger.
Übernehmen Sie Aufgaben zur PR-Prüfung und Projektvalidierung. Verwenden Sie separate Arbeitsverzeichnisse und Cache-Schlüssel. Laden Sie anschließend Testergebnisse, Build-Logs und Commit-Kennung in den Artefaktspeicher des Teams hoch.
Übernehmen Sie geprüfte Commits oder Release-Tags. Prüfen Sie die Toolchain-Version und führen Sie den Archive-Schritt unabhängig aus. Autorisieren Sie Release-Aufgaben separat, damit nicht mehrere Standorte denselben Release-Vorgang starten.
Ein standortübergreifender Einsatz verschiebt keine laufenden Aufgaben automatisch und bietet kein automatisches Failover. Wenn Sie Redundanz benötigen, legen Sie in Ihrer CI Wiederholungsbedingungen, Parallelitätsgrenzen und Sperren für Releases fest. Testen Sie außerdem die Wiederherstellung nach einer Unterbrechung.
Prüfen Sie Modell, Standort und Abrechnungszeitraum in der Konsole. Beide Modelle sind an allen fünf Standorten verfügbar; die aktuelle Verfügbarkeit sehen Sie in Echtzeit in der Konsole.
Zahlung per USDT-TRC20 oder Visa / Mastercard / Amex (über Stripe); Abrechnung in USD.