Deine Aufgaben bestimmen, welchen Mac du mietest
Ein Cloud-Mac ist ein kompletter, exklusiv für dich verfügbarer physischer Mac mini – keine aufgeteilte virtuelle Maschine. Nutze ihn für iOS-Builds, den macOS-Desktop oder kurzfristige Experimente mit voller Rechenleistung. Wähle zuerst deine Workload und dann Konfiguration, Standort und Mietdauer: täglich, wöchentlich, monatlich oder quartalsweise.
Zwei M4-Konfigurationen · ab $21.4/Tag · in ca. 4 Minuten verfügbar. Die aktuelle Verfügbarkeit siehst du direkt in der Konsole.
Erst die Auslastung, dann die Mietdauer festlegen
Vom einzelnen Build zur stabilen Build-Pipeline.
Die Workload bestimmt den Einsatz
Alle fünf Szenarien starten mit demselben dedizierten Mac. Welche Dateien, Verbindung und Mietdauer sinnvoll sind, hängt jedoch von der jeweiligen Aufgabe ab.
iOS-Builds aus gemeinsam genutzten Warteschlangen herausholen
Binde den Cloud-Mac als Self-hosted Runner ein – einen von dir verwalteten Rechner, der CI-Jobs exklusiv ausführt. PR-Checks und Nightly-Builds laufen dann auf diesem Mac, ohne dass du dir die Hardware mit anderen Kunden teilen musst.
Drei Schritte für die Einrichtung
- Richte die Build-Umgebung mit der vom Repository benötigten Xcode-Version ein und ordne die Runner-Labels den Projekt-Jobs zu.
- Lege Dependency-Cache und DerivedData an festen Speicherorten ab, damit nicht bei jedem Job alles erneut heruntergeladen wird.
- Beschränke den Zugriff auf Signaturmaterial auf Jobs, die ein Release erstellen. Analysiere fehlgeschlagene Builds in den CI-Systemen deines Teams.
Konfigurationsempfehlung Für eine einzelne App, Fastlane und Unit-Tests genügt zunächst der XV M4 Runner; für kurzfristige Releases kannst du tage- oder wochenweise mieten. Wenn mehr Jobs parallel laufen, vergleiche zusätzliche Rechner mit einem Wechsel zum Studio.
Build und Signierung in einer sauberen macOS-Umgebung
Kurz vor dem Einreichen ist es besonders wichtig, dass die lokale Toolchain mit der des letzten Releases übereinstimmt. Erstelle das Archive, prüfe die Signierung und lade die App über denselben Cloud-Mac zu App Store Connect hoch. So lassen sich Build-Protokolle, Zertifikatsspeicherorte und Artefaktpfade leichter überprüfen.
Die Release-Schritte der Reihe nach prüfen
- Lege zuerst die benötigte Xcode-Version und die Abhängigkeiten fest und erstelle anschließend ein reproduzierbares Archive.
- Prüfe, ob Signaturzertifikat und Provisioning Profile zur Ziel-App passen. Speichere vertrauliche Daten nicht direkt im Repository.
- Prüfe die exportierten Artefakte vor dem Upload. Sichere Protokolle, Archive und alle benötigten Dateien, bevor die Mietdauer endet.
Konfigurationsempfehlung Für den gebündelten Build einer einzelnen App kannst du mit dem XV M4 Runner starten. Bei mehreren Targets und Simulatoren parallel ist der XV M4 Studio die passende Wahl; plane die Mietdauer für den gesamten Release-Zyklus ein.
iOS-Artefakte aus verschiedenen Frameworks zentral erstellen
Die tägliche Entwicklung mit React Native, Flutter oder Unity kann auf unterschiedlichen Systemen stattfinden – für den abschließenden iOS-Build ist jedoch die macOS-Toolchain erforderlich. Bündele die iOS-Builds der jeweiligen Projekte auf einem Cloud-Mac, damit dein Team die Artefakte mit derselben Xcode-Umgebung prüfen kann.
Eingaben vor der Migration vorbereiten
- Halte die erforderlichen Versionen von Frameworks, Plugins und Xcode fest. Lass zuerst einen minimalen Build erfolgreich durchlaufen und binde danach die vollständige Pipeline ein.
- Unterscheide zwischen Quellcode-Cache, Dependency-Cache und finalem Archive. Bereinige den Cache nicht, um Speicherplatzprobleme zu kaschieren.
- Wenn mehrere Projekte gleichzeitig kompiliert oder parallel per Remote-Desktop debuggt werden, solltest du genügend Arbeitsspeicher und SSD-Speicherplatz einplanen.
Konfigurationsempfehlung Bei Builds nacheinander solltest du zuerst prüfen, ob 16 GB RAM und eine 256-GB-SSD im Runner ausreichen. Für mehrere Projekte parallel empfiehlt sich der Studio mit 24 GB RAM und einer 512-GB-SSD.
Netzwerkleistung über Standorte im asiatisch-pazifischen Raum prüfen
Zur Auswahl stehen Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong – insgesamt vier Standorte. Wähle einen Standort in der Nähe deiner Zielgruppe, führe die Tests auf dem dortigen Mac aus und vergleiche die Ergebnisse mit lokalen Tests.
Standort im Testprotokoll festhalten
- Dokumentiere Standort, Testgerät und Netzwerkbedingungen. Ein einzelnes Verbindungsergebnis sagt nichts über eine ganze Region aus.
- Auch die Bedienung per Remote-Desktop hängt von der Entfernung zum Standort ab. Wähle für interaktive Tests zunächst einen möglichst nahen Standort.
- Halte bei Vergleichen zwischen Standorten Projektversion und Testablauf konstant. Beide Modelle sind an allen vier Standorten verfügbar; die aktuelle Verfügbarkeit siehst du direkt in der Konsole.
Konfigurationsempfehlung Für einen einzelnen Test kannst du mit dem Runner und einer Tagesmiete beginnen. Wenn du fortlaufende Regressionstests oder mehrere Simulatoren parallel brauchst, prüfe den Studio und eine längere Mietdauer.
Einen eigenen Mac für Inferenzexperimente mit Apple Silicon nutzen
Teste MLX oder llama.cpp auf dem gemeinsamen Arbeitsspeicher von Apple Silicon, ohne für einen kurzfristigen Versuch gleich Hardware anzuschaffen. Ob ein quantisiertes Modell mit etwa 7B–13B Parametern auf der gewählten Konfiguration läuft, hängt auch von der Quantisierung, der Kontextlänge und parallel laufenden Aufgaben ab.
Mit einem kleinen Testlauf beginnen
- Lade zunächst ein Modell und wenige Test-Prompts herunter. Beobachte dann den tatsächlichen RAM-Verbrauch, den freien SSD-Speicher und die Antwortzeit.
- Speichere Modellgewichte, Versuchsergebnisse und Umgebungsinformationen getrennt. Wenn du mehr Gewichte vorhalten möchtest, kannst du eine zusätzliche 1-TB-SSD wählen.
- Exportiere Ergebnisse und alle Dateien, die du behalten möchtest, bevor das Experiment endet. Nach Ablauf der Mietdauer wird die gesamte Festplatte zurückgesetzt.
Konfigurationsempfehlung Starte mit dem XV M4 Studio mit 24 GB RAM und einer 512-GB-SSD. Eine Tagesmiete eignet sich für den ersten Machbarkeitstest; zusätzlichen Speicher solltest du passend zur Größe der Modellgewichte wählen.
Workload, Modell und Mietdauer aufeinander abstimmen
Diese Tabelle dient als Ausgangspunkt und ersetzt keine Messung von RAM- und Speicherbedarf sowie Parallelität in deinem Projekt. Im Angebot stehen zwei M4-Modelle; eine zusätzliche SSD und Thunderbolt-5-Verbindung kannst du bei Bedarf ergänzen.
| Workload | Empfohlene Konfiguration | Mietdauer zum Einstieg | Auswahlkriterien |
|---|---|---|---|
| Leichte Builds Einzelne App, Fastlane, Unit-Tests |
XV M4 Runner M4 / 16 GB / 256 GB |
Tages- oder Wochenmiete | Lass zunächst eine vollständige Pipeline durchlaufen und entscheide anhand der tatsächlichen Warteschlangenlänge, ob du die Mietdauer verlängerst. |
| Tägliche Entwicklung Mehrere Targets, mehrere Simulatoren, Remote-Desktop |
XV M4 Studio M4 / 24 GB / 512 GB |
Monatsmiete | Führe paralleles Debugging, Build-Caches und Desktop-Sitzungen auf demselben Rechner aus. |
| Inferenz mit quantisierten Modellen Ca. 7B–13B Parameter, tatsächlichen Bedarf zuerst testen |
XV M4 Studio M4 / 24 GB / 512 GB, optional +1 TB SSD |
Zunächst tageweise testen | Lege Modell und Kontextgröße anhand von Messungen fest. Eine zusätzliche SSD bietet Platz für Gewichte, erhöht aber nicht den gemeinsamen Arbeitsspeicher. |
| Builds im Team skalieren Mehrere Projekte oder parallele Pipelines |
Mehrere XV M4 Studio Pro Gerät M4 / 24 GB / 512 GB, optional mit Thunderbolt 5 verbunden |
Mietdauer passend zum Projekt wählen | Weise zuerst Runner-Labels und Jobs zu. Prüfe danach, ob die Rechner tatsächlich eine schnelle Verbindung untereinander benötigen. |
Richtpreise zum Einstieg: Runner $21.4/Tag, Studio $40.7/Tag; zusätzliche 1-TB-SSD $2.4/Tag, Thunderbolt-5-Verbindung $1/Tag pro Gerät. Preise für Wochen-, Monats- und Quartalsmieten sowie weitere Extras findest du im Alle Mietoptionen ansehen.
In vier Schritten starten – ohne lange Mietdauer
Wenn du beim Umfang der Parallelität noch unsicher bist, teste zuerst einen echten Build oder ein Experiment. Bereite vor der Buchung die Daten vor, die du behalten möchtest, deinen SSH-Public-Key und die Projektabhängigkeiten.
- 01
Workload auswählen
Lege fest, ob du CI, Releases, plattformübergreifende Builds, Tests in Zielnähe oder Inferenzexperimente durchführen möchtest, und schätze die benötigte Laufzeit ab.
- 02
Konfiguration in der Tabelle finden
Wähle Runner oder Studio anhand von RAM, Speicherplatz und parallelen Aufgaben. Für Netzwerktests vor Ort kannst du anschließend einen der vier Standorte im asiatisch-pazifischen Raum wählen.
- 03
Konfigurieren und buchen
Wähle Tages-, Wochen-, Monats- oder Quartalsmiete und die gewünschten Extras. Die Zahlung ist ausschließlich mit USDT-TRC20 oder Visa, Mastercard und Amex über Stripe möglich; abgerechnet wird in US-Dollar.
- 04
Verbinden und prüfen
Teste nach Erhalt der Zugangsdaten zuerst SSH und Remote-Desktop. Führe anschließend eine repräsentative Aufgabe aus und halte Version, Laufzeit und Speicherverbrauch fest.
Miete für einen Tag und bring deinen ersten Job zum Laufen.
Starte mit dem XV M4 Runner ab $21.4/Tag. Wenn du bereits weißt, dass du mehr parallele Aufgaben oder mehr Arbeitsspeicher brauchst, wähle direkt den XV M4 Studio. Bei beiden Modellen steht dir der komplette Rechner exklusiv zur Verfügung.