Für Teams in Ostasien: Führen Sie iOS-Builds und Remote-Entwicklung auf einem dedizierten physischen Mac aus. Keine VM – macOS mit grafischer Oberfläche und Kommandozeile steht vollständig zur Verfügung. Bringen Sie zunächst eine Pipeline zum Laufen und entscheiden Sie danach, ob Sie weitere Knoten benötigen.
Drei Konfigurationen, vier Abrechnungszeiträume, ab $21.1/Tag. Verfügbarkeit in Echtzeit sehen Sie in der Konsole.
Alle drei Tarife bieten einen dedizierten physischen Knoten. Der Arbeitsspeicher bestimmt, wie viele Builds und Tests gleichzeitig Platz finden. Die SSD legt den Spielraum für Repository, Toolchain und Cache fest. Wählen Sie nicht allein nach der Zahl täglicher Builds, sondern berücksichtigen Sie auch den Spitzenbedarf eines einzelnen Builds.
Aktuell ist der Tagespreis hervorgehoben. Bestätigen Sie Abrechnungszeitraum und Standort im Konfigurator.
Ideal für die erste iOS-Pipeline, automatisierte Archivierung und leichtere Entwicklungsaufgaben. Lassen Sie zunächst einen Runner sequenziell arbeiten und beobachten Sie den Speicher- und Cachebedarf.
$21.1/Tag
Ziehen Sie System, Xcode und Abhängigkeiten zuerst vom Speicherbudget ab. Planen Sie danach Platz für DerivedData und aufbewahrte Archive ein.
Für dauerhaft laufende Runner, mehrere Abhängigkeitssätze und Projekte mit größerem Build-Cache. Mehr Unified Memory und lokaler Speicher als beim Einstiegsmodell.
$41.4/Tag
Mehrere Schemes können zunächst nacheinander laufen. Ob sich parallele Builds lohnen, zeigen Spitzenbedarf und Laufzeit in der Praxis.
Für größere Projekte, Tests mit mehreren Simulatoren und lokale Modellinferenz. 64GB Unified Memory und eine 2TB SSD bieten mehr Spielraum für anspruchsvolle Aufgaben.
$59.5/Tag
Eine höhere Ausstattung bedeutet nicht unbegrenzte Parallelität. Testen Sie zuerst eine echte Aufgabe und erhöhen Sie dann schrittweise die Zahl gleichzeitiger Jobs.
Die Preise gelten für die Miete des jeweiligen Mac und werden in US-Dollar abgerechnet. Wenn Sie mehr SSD-Speicher oder Thunderbolt-5-Verbindungen benötigen, prüfen Sie die Zusatzoptionen im vollständigen Tarifangebot. Verbindlich ist der Gesamtpreis im Konfigurator. Mit den Tarif-Buttons wird die jeweilige Konfiguration vorausgewählt; Standort und Zeitraum bestätigen Sie auf der Bestellseite.
Der Richtwert für die durchschnittliche Latenz aus Ostasien liegt bei 30~60ms. Er dient der Orientierung bei der Standortwahl, ist keine Messung Ihrer aktuellen Verbindung und keine Latenzgarantie für einzelne Internetanbieter.
30~60ms
Gilt für: Ostasien → Tokio
Das tatsächliche Nutzungserlebnis hängt von Ihrem Anschluss, dem Routing zwischen Netzen, der Tageszeit und den Anzeigeeinstellungen ab. Eingabelatenz, Dateiübertragung und Build-Dauer sind unterschiedliche Kennzahlen.
Die Knoten sind 365 Tage im Jahr in Betrieb. Für langfristige Builds sollten Repository-Spiegel, Sicherungskopien und archivierte Artefakte vorhanden sein. Der Runner dient als reproduzierbare Build-Umgebung.
Die folgenden Zeitangaben sind Schätzwerte für die Einrichtung, wenn alle Informationen vorliegen. Sie sind keine Zusage für Bereitstellung oder Build-Dauer. Wartezeiten für Zahlungsbestätigung, Bereitstellung der Instanz und Projektdownload kommen hinzu. Maßgeblich ist der Fortschritt in der Konsole.
Etwa 2–5 Minuten. Wählen Sie Konfiguration, Standort und Abrechnungszeitraum und prüfen Sie Zusatzoptionen und Gesamtpreis. Für einen kurzen Test bietet sich die Tagesmiete an. Bevor Sie länger mieten, testen Sie Ihr echtes Projekt.
Etwa 3–5 Minuten, ohne Wartezeit auf die Zahlungsbestätigung. Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe); abgerechnet wird in US-Dollar. Welche Zahlungsoption verfügbar ist, zeigt die Backend-Schnittstelle an.
Nach Bereitstellung der Zugangsdaten etwa 5–10 Minuten. Rufen Sie die Hostdaten in der Konsole ab und verbinden Sie sich per SSH oder VNC. Prüfen Sie den Hostnamen, ändern Sie das initiale Passwort und hinterlegen Sie Ihren SSH-Public-Key.
Etwa 10–20 Minuten für die Einrichtung, ohne Tool-Downloads und Build-Laufzeit. Prüfen Sie die Versionen von Xcode und den Kommandozeilenwerkzeugen, hinterlegen Sie das benötigte Signaturmaterial, registrieren Sie den Runner und kontrollieren Sie anschließend Archive und Logs auf Vollständigkeit.
Halten Sie vorab Repository-Zugriff, Abhängigkeitsliste, gewünschte Xcode-Version und Signaturmaterial bereit. Speichern Sie weder private Schlüssel noch Zertifikatpasswörter oder vollständige Zugangsdaten in Build-Logs.
Der nächstgelegene Standort ist nicht automatisch die beste Wahl. Entscheidend ist, ob der Zugang Ihres Teams, das Netzwerk Ihres Repositorys und der Weg der Build-Artefakte zuverlässig zusammenspielen.
Tokio ist eine gute Option für den ersten Test, aber entscheiden Sie nicht allein nach der geografischen Lage. Beim Remote-Debugging zählt vor allem die Bedienung zwischen Team und Host. Automatisierte Builds hängen stärker von der Verbindung des Hosts zu Repository, Abhängigkeitsquellen und Artefakt-Ziel ab. Testen Sie den vollständigen Ablauf über Ihr übliches Netzwerk, bevor Sie eine längere Laufzeit wählen.
Das lässt sich daraus nicht ableiten. Der Wert ist ein Richtwert für die durchschnittliche Latenz aus Ostasien und beschreibt nur die Größenordnung der Netzwerklaufzeit. Die Build-Dauer hängt außerdem von Projektgröße, Chip, Arbeitsspeicher, Cache-Treffern und Signierschritten ab. Erfassen Sie Builds mit leerem und warmem Cache getrennt, um die passende Konfiguration zu beurteilen.
Mit den Tarif-Buttons auf dieser Seite wird die passende Konfiguration vorausgewählt. Wählen Sie im Konfigurator anschließend Tokio und den Abrechnungszeitraum aus. Prüfen Sie vor der Zahlung Tarif, Standort, Speichererweiterungen und Gesamtbetrag in der Bestellung. Der Seitentitel bestätigt keine Bestellung – maßgeblich sind die Auswahl im Konfigurator und die endgültige Bestellübersicht.
Mieten Sie einen dedizierten physischen Mac tageweise und erfassen Sie Laufzeit, Speicher- und Festplattenbedarf Ihres echten Projekts. Entscheiden Sie anhand Ihrer Build-Ergebnisse über Konfiguration und Mietdauer.