Welcher Mac soll Ihre Xcode-Builds ausführen? Entscheidend ist zuerst, wer ihn dauerhaft verfügbar hält.
Ein dedizierter Mac zur Miete, selbst gekaufte Hardware oder eine geteilte VM – alle drei Optionen eignen sich für bestimmte macOS-Workloads. Es geht nicht nur um die Zahlungsart, sondern auch um Ressourcenzuweisung, Cache-Lebensdauer und die Frage, wer nächtliche Build-Ausfälle behebt.
PushMac ab $19.2 pro Tag · kompletter physischer Mac mini · keine VM
Ausgangspunkt ist ein Team, das Xcode benötigt. Die Mietoption steht für PushMac; die geteilte Option beschreibt gängige temporäre macOS-Build-Umgebungen. Preise, Warteschlangen und Persistenz sollten Sie für die jeweilige Plattform einzeln prüfen.
| Kriterium | Dedizierten Mac mieten | Hardware kaufen | Geteilte VM |
|---|---|---|---|
| Kostenmodell | Ab $19.2 pro Tag; Abrechnung nach gewähltem Modell, Laufzeit und Zusatzoptionen. | Einmalige Anschaffungskosten plus Strom, Internet, Hosting oder Stellfläche; auch den Personalaufwand einrechnen. | Manche Plattformen rechnen pro Minute oder Job ab; Warteschlangen, Parallelität und zusätzlicher Speicher sind je nach Plattform unterschiedlich geregelt. |
| Bereitstellung | Noch am selben Tag verfügbar: Nach Zahlungseingang wird ein kompletter Rechner zugewiesen und die Verbindungsinfo in der Konsole bereitgestellt. | Beschaffung, Versand, Rack-Montage und Netzwerkkonfiguration folgen nacheinander. Planen Sie meist mehrere Tage oder mehr ein. | Umgebungen lassen sich schnell erstellen; wann ein Job tatsächlich startet, hängt jedoch von verfügbaren Kontingenten und der Warteschlange ab. |
| Exklusive Ressourcen | Ein physischer Mac mini wird exklusiv an einen Kunden vermietet und nicht mit anderen Kunden auf demselben Host geteilt. | Der ganze Rechner steht exklusiv zur Verfügung; Hardware, Strom und Netzwerk organisieren Sie selbst. | Die virtuelle Umgebung teilt sich den Host mit anderen Mietern; die Plattform legt Isolation und Kontingente fest. |
| Upgrades und Migration | Je nach Job können Sie ein anderes Modell oder einen anderen Standort wählen. Beim Wechsel einer Instanz müssen Code, Cache und CI-Konfiguration migriert werden. | Bei unzureichender Hardware müssen Sie Geräte anschaffen oder austauschen; für den Betrieb in mehreren Regionen ist außerdem lokales Hosting nötig. | Abhängig von den verfügbaren Spezifikationen, Parallelitätskontingenten und Standorten der Plattform. |
| Cache und Toolchain | Während der Mietdauer können Sie DerivedData, Abhängigkeits-Caches und mehrere Xcode-Versionen selbst vorhalten. | Dauerhafte Speicherung ist möglich; Datenträgerbereinigung, Backups und Versionsverwaltung liegen beim Team. | Nach Ende einer temporären Instanz können lokale Dateien gelöscht werden. Für dauerhafte Caches ist meist eine separate Persistenzlösung nötig. |
| Verantwortung für die Infrastruktur | Das Rechenzentrum kümmert sich um Strom, Netzwerk und Kühlung; das Team verwaltet Code, Systemkonfiguration und Build-Jobs. | Alles selbst verwalten oder Hosting, Netzwerk und Bereitschaftsdienst separat beauftragen. | Die Plattform verwaltet Host und Scheduling; das Team muss Images, Job-Limits und Betriebsregeln berücksichtigen. |
| Besonders geeignet für | Dauerbetrieb, selbst gehostete Runner, feste Toolchains und die Zusammenarbeit verteilter Teams. | Vorhandenes Hosting, erforderlicher Zugriff auf Geräte vor Ort und Bereitschaft, den Eigenbetrieb zu übernehmen. | Kurze, reproduzierbare Einzeljobs, bei denen Warteschlangen und zurückgesetzte Umgebungen tolerierbar sind. |
Exklusive Nutzung bedeutet nicht, dass keine Verwaltung nötig ist. Das Team muss weiterhin Regeln für Zertifikate, Zugriffsschlüssel, Abhängigkeitsversionen, Job-Warteschlangen und Datensicherungen festlegen.
Geräte im Büro bedeuten nicht, dass der Betrieb kostenlos ist. Berücksichtigen Sie diese vier Punkte bei der Beschaffung – insbesondere, wer nachts handelt, wenn niemand vor Ort ist.
Im Eigenbetrieb müssen Sie Stromversorgung, Wiederanlauf nach einem Stromausfall und Unterstützung vor Ort organisieren. Sobald der Rechner wieder läuft, müssen auch Runner und Build-Dienste geprüft werden.
Bei gemieteter Infrastruktur:
Das Rechenzentrum stellt den Strom bereit; das Team prüft die Startkonfiguration seiner Dienste.
Im Eigenbetrieb müssen Sie Netzwerkstabilität, Fernzugriff und Leitungsstörungen im Blick behalten. Eine funktionierende Desktop-Verbindung garantiert nicht, dass Repository-Zugriffe, Downloads von Abhängigkeiten und Uploads von Artefakten ebenfalls funktionieren.
Bei gemieteter Infrastruktur:
Das Rechenzentrum stellt das Netzwerk bereit; das Team verwaltet SSH-Schlüssel und Zugriffsregeln auf Anwendungsebene.
Längere Archive-, Test- oder Dependency-Builds erzeugen anhaltende Last. Im Eigenbetrieb müssen Sie für Belüftung, Umgebungstemperatur und Kontrollen vor Ort sorgen.
Bei gemieteter Infrastruktur:
Das Rechenzentrum übernimmt die Kühlung; das Team beobachtet Job-Auslastung und Speicherverbrauch.
Unterscheiden Sie vorab zwischen einem nicht erreichbaren Rechner, einem gestoppten Runner und einem fehlgeschlagenen Skript. Ohne klare Bereitschaftsregel kann sich die Release-Warteschlange bereits stauen, bevor am nächsten Morgen die Fehlermeldung eintrifft.
Bei gemieteter Infrastruktur:
Infrastrukturprobleme werden über ein Support-Ticket in der Konsole gemeldet; Fehler in Code und Pipeline behebt das Team.
PushMac-Knoten laufen das ganze Jahr. Die durchgehend verfügbare Hardware ermöglicht nächtliche CI-Builds; ob ein Build erfolgreich ist, hängt weiterhin von Projekt, Abhängigkeiten und Job-Konfiguration ab.
Eine geteilte VM ist kein exklusiver physischer Rechner, sollte aber nicht pauschal ausgeschlossen werden. Klären Sie die Laufzeitbeschränkungen, um zu beurteilen, ob sie für temporäre Jobs geeignet ist oder im täglichen CI mehr Wartezeit und Neuaufbau verursacht.
Erfassen Sie die Zeiten für Warteschlange, Initialisierung, Abhängigkeits-Downloads, Kompilierung und Upload getrennt. Ähnliche Archive-Zeiten bei demselben Projekt bedeuten nicht, dass die Gesamtzeit vom Commit bis zum fertigen Artefakt ebenfalls ähnlich ist.
Prüfen Sie: Parallelitätskontingente, Job-Limits, Startwartezeit und die Frage, ob Ressourcenkontingente fest zugesichert sind.
Wird die Instanz nach dem Job gelöscht, sind lokale Pods, SPM oder DerivedData kein dauerhafter Speicher. Bei einem Remote-Cache müssen Sie zusätzlich Wiederherstellungszeit, Kapazität und Pflege der Cache-Schlüssel berücksichtigen.
Prüfen Sie: Regeln zur Instanzlöschung, Cache-Aufbewahrungsdauer und Invalidierungsstrategie beim Wechsel der Xcode-Version.
Eine virtuelle Umgebung kann Jobs voneinander isolieren, bedeutet aber nicht, dass Ihnen der ganze Rechner gehört. Wenn Sie dauerhaft verfügbare Dienste, eine feste Toolchain oder umfassendere Systemrechte benötigen, prüfen Sie, ob die Plattform das zulässt.
Prüfen Sie: Systemrechte, Hintergrundprozesse, Einschränkungen bei der Tool-Installation und verfügbare Regionen.
Wenn Teammitglieder an zwei Standorten arbeiten, unterscheiden Sie zuerst den Bedarf an interaktivem Remote-Desktop vom Bedarf an Hintergrund-Builds. Die Zeitzone bestimmt, wer Bereitschaft hat; die Netzwerkroute beeinflusst die Verbindung. Das eine ersetzt das andere nicht.
Singapur · Tokio · Seoul · Hongkong · US-Ostküste
Beide Mac-Modelle sind an allen Standorten verfügbar. Den aktuellen Verfügbarkeitsstatus sehen Sie in der Konsole; prüfen Sie die Qualität der Remote-Verbindung anhand des Teamstandorts und des tatsächlichen Netzwerks.
Wählen Sie jeweils einen nahegelegenen Standort in Asien-Pazifik und Nordamerika und weisen Sie Jobs über unterschiedliche Runner-Tags zu. Der Code wird aus demselben Repository bezogen, Artefakte an einem zentralen Teamstandort abgelegt. So müssen Sie die Regionen nicht bei jedem interaktiven Vorgang synchronisieren.
Auch mit nur einem Rechner können Teams je nach Arbeitszeit im Wechsel arbeiten, brauchen dafür aber eine gemeinsame Build-Warteschlange. Xcode-Wechsel, Cache-Bereinigung oder die Nutzung von Signaturressourcen können sich auf demselben Rechner weiterhin gegenseitig beeinträchtigen.
Einzuplanen: Standorte, Runner-Tags, Warteschlange und Regeln zur Artefaktablage.
Ein Gerät an jedem Standort bedeutet neben der Anschaffung auch, Strom, Netzwerk, Kühlung und Unterstützung vor Ort separat zu organisieren. Die Geräte gehören Ihnen, doch ein standortübergreifender Betrieb löst das Problem der Fernbetreuung nicht von selbst.
Steht die Hardware nur in einem Büro, ist der Remote-Desktop-Zugriff vom anderen Standort weiterhin von der Netzwerkverbindung über die Regionen abhängig. Das eignet sich für Teams mit lokalen Räumlichkeiten und Betriebskapazitäten, die Zuständigkeiten klar regeln können.
Einzuplanen: Lokales Hosting, Zugriffsweg, Wiederherstellungsprozess und Verantwortliche.
Prüfen Sie zuerst, welche Regionen die Plattform abdeckt, und anschließend die Parallelitätskontingente während der Arbeitszeiten an beiden Standorten. Automatisieren Sie bei temporären Umgebungen die Toolchain-Installation und Cache-Wiederherstellung, damit keine manuellen Änderungen einer bestimmten Maschine vorausgesetzt werden.
Geeignet für Pipelines, die sich in unabhängige Jobs aufteilen lassen. Wenn Sie eine feste Desktop-Umgebung, dauerhaft laufende Prozesse oder umfangreiche lokale Zustände benötigen, testen Sie diese Funktionen vor der Migration.
Einzuplanen: Standortübersicht, Kontingente, Images und Strategie zur Cache-Wiederherstellung.
Protokollieren Sie je einen Build mit kaltem und warmem Cache und halten Sie Verbindungsqualität, Vorbereitungszeit und Artefakt-Upload gemeinsam fest. Eine tageweise Miete eignet sich für erste Migrationstests und Builds. Entscheiden Sie nicht allein anhand der Modellbezeichnung über den tatsächlichen Nutzen für Ihr Team.
Wenn Sie dauerhafte Verfügbarkeit, exklusive Ressourcen und erhaltene Build-Caches benötigen, aber Strom, Netzwerk und Kühlung nicht selbst verwalten möchten, passt ein gemieteter exklusiver physischer Mac mini zu diesen Anforderungen. Bei vorhandenen Geräten vor Ort und etabliertem Eigenbetrieb kann sich ein Kauf weiterhin lohnen. Für kurze, reproduzierbare Jobs können Sie geteilte Umgebungen prüfen.
Push M4 S: M4 / 16GB / 256GB SSD – für das tägliche CI einer einzelnen App. Push M4 L: M4 / 24GB / 512GB SSD – für parallele Archive mehrerer Targets und gemischte Flutter- / React-Native-Builds. Prüfen Sie die tatsächliche Parallelität anhand des Speicherbedarfs Ihres Projekts; die Spezifikationen lassen sich nicht direkt in einen festen Geschwindigkeitszuwachs umrechnen.
Die tageweise Miete eignet sich für Migrationstests und die Validierung des ersten Builds. Wochen-, Monats- und Quartalspreise finden Sie vollständig auf der Angebotsseite. Bezahlt werden kann mit USDT-TRC20 sowie Visa / Mastercard / Amex über Stripe. Abgerechnet wird in US-Dollar; welche Zahlungsmethoden verfügbar sind, richtet sich nach der Rückmeldung des Backends.
Ein exklusiver Mac mini, 365 Tage im Jahr verfügbar. Wählen Sie ein Angebot und integrieren Sie Ihr Projekt in die eigene Build-Warteschlange.