Am Beispiel einer iOS-Build-Pipeline
Prüfen Sie zuerst, wer die gesamte Maschine nutzt, und vergleichen Sie anschließend Kosten und Betriebsaufwand. XCRent bietet dedizierte physische Mac mini – keine virtuellen Maschinen – zur tage-, wochen-, monats- oder quartalsweisen Miete. Ob das zu Ihrem Projekt passt, zeigen derselbe Quellcode und dieselben Build-Protokolle.
Ab $21.7 pro Tag. Erst testen, dann über die Mietdauer entscheiden.
Verglichen werden die Service-Modelle, nicht die Benchmark-Werte verschiedener Chips. Bei gemeinsam genutzten Plattformen sollten Sie Preise, Warteschlangen und Ressourcenlimits des konkreten Angebots prüfen. Beim Kauf gehören auch Einrichtung und laufender Betrieb ins Budget.
| Kriterium | Dedizierten Cloud-Mac mieten | Hardware kaufen | Virtuelle Maschine teilen |
|---|---|---|---|
| Kosten | XR Build 16 ab $108.3/Monat. Die Miete pro Server ist klar ausgewiesen; Ihr Team muss weiterhin Projekt, Zertifikate und Pipeline betreuen. | Einmalige Anschaffung plus Stellfläche, Netzwerk, Strom, Backups und Hardwareverwaltung. Ein Vergleich allein von Kaufpreis und Miete greift zu kurz. | Abrechnung möglicherweise pro Minute oder Build-Aufgabe. Prüfen Sie, ob Start, Installation von Abhängigkeiten, Wartezeit und Artefaktspeicher berechnet werden – nicht nur die reine Build-Zeit. |
| Bereitstellung | Nach der Bestellung wird ein physischer Server zugewiesen, auf dem macOS und Xcode vorinstalliert sind. Verfügbarkeit und Betriebsstatus sehen Sie in Echtzeit im Portal. | Bestellen, Lieferung und Installation, anschließend Remote-Zugriff, Toolchain und Build-Benutzer einrichten. Wann das System einsatzbereit ist, hängt von Ihren Abläufen ab. | Umgebungen lassen sich meist bei Bedarf erstellen. Verfügbare Konfigurationen, Startzeiten und Warteschlangen richten sich nach den Ressourcen und Regeln der Plattform. |
| Exklusivität | Der gesamte physische Server ist einem einzigen Kunden vorbehalten. Xcode-Builds, Simulatoren und Schlüsselbund werden nicht mit anderen Kunden auf demselben System geteilt. | Die Hardware gehört Ihrem Team. Ob sie ausschließlich fürs Bauen genutzt oder auch für die tägliche Entwicklung eingesetzt wird, entscheiden Sie selbst. | Virtuelle Maschinen können auf Systemebene isoliert sein, während die zugrunde liegenden physischen Ressourcen mehreren Kunden dienen. Eine VM ist nicht gleichbedeutend mit einem exklusiven Server. |
| Upgrades | Sie können im Portal ein Upgrade anfragen oder eine zusätzliche SSD mit +1TB / +2TB konfigurieren. Klären Sie vorab, wie die Änderung umgesetzt wird und ob Daten migriert werden müssen. | Sie müssen zusätzliche Geräte kaufen oder die Hardware-Konfiguration ändern. Für neue Maschinen sind Netzwerk, Fernverwaltung und Build-Umgebung ebenfalls einzurichten. | Die Möglichkeiten hängen von den verfügbaren Konfigurationen und Funktionen der Plattform ab. Prüfen Sie Arbeitsspeicher, Speicherplatz, persistente Caches und Parallelitätslimits; Erweiterungen sind nicht automatisch frei verfügbar. |
| Cache und Zustand | Quellcode-Verzeichnisse, Abhängigkeits-Caches und DerivedData lassen sich selbst verwalten. Legen Sie Regeln zum Bereinigen fest, damit der Systemdatenträger nicht vollläuft. | Sie verwalten Cache und Systemzustand ganz nach Ihren Anforderungen, sind aber auch für Speicherwarnungen, Backups und Wiederherstellung zuständig. | Prüfen Sie, ob die Umgebung nach einem Build gelöscht wird, wie Caches wiederhergestellt werden, ob die Wiederherstellung berechnet wird und welche Verzeichnisse dauerhaft gespeichert werden können. |
| Betrieb | Die Plattform betreibt den physischen Server. Sie kümmern sich um Projekt, Software-Konfiguration, Zertifikatsrechte, Zugangsdaten und Backups Ihrer Geschäftsdaten. | Ihr Team verantwortet Hardware, System, Netzwerk und Projektbetrieb. Klären Sie außerdem, wer bei einem Geräteausfall einspringt und welche Ersatzlösung bereitsteht. | Die Plattform verwaltet die Basisumgebung; Ihr Team muss sich auf deren Aufgabenlebenszyklus, Image-Updates und Berechtigungsmodell einstellen. Bei Fehlern gilt es, Plattform- und Projektprobleme auseinanderzuhalten. |
Die Tabelle vergleicht Rahmenbedingungen. Sie sagt nicht aus, dass alle gemeinsam genutzten Dienste dieselben Wartezeiten haben, und garantiert keine feste Build-Dauer für eine bestimmte Konfiguration.
Angenommen, dasselbe Team nutzt dauerhaft einen XR Build 24: M4 / 24GB / 512GB. Die 20 Builds sind eine Annahme zum Arbeitsvolumen, keine Leistungszusage und keine Erlaubnis, 20 Builds gleichzeitig auszuführen.
Bei der Annahme von 30 Tagen pro Monat und 90 Tagen pro Quartal sind 600 Builds pro Monat beziehungsweise 1.800 pro Quartal geplant. Wie viele Builds tatsächlich erfolgreich sind, wie oft sie wiederholt werden und wie lange sie warten, entnehmen Sie Ihren eigenen Pipeline-Protokollen.
$204.1 / Monat
Geeignet, wenn Sie ein Projekt gerade migrieren, die Toolchain noch anpassen oder die langfristige Auslastung noch nicht kennen. Führen Sie zunächst einen vollständigen Archive-Build inklusive Signierung und Artefakt-Export aus.
Prüfen Sie, ob die tägliche Build-Warteschlange dauerhaft bewältigt wird.
$555.2 / Quartal
Geeignet für eine bewährte Umgebung und eine Pipeline, die voraussichtlich dauerhaft genutzt wird. Verglichen über drei Monate sparen Sie gegenüber drei Monatszahlungen $57.1.
Ersparnis: $204.1 × 3 − $555.2 = $57.1
Der Vergleich berücksichtigt nur die Servermiete, keine Speichererweiterung und keine Thunderbolt-5-Verbindung mehrerer Geräte. Zahlungen sind ausschließlich mit USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe) möglich; abgerechnet wird in US-Dollar. Welche Zahlungswege verfügbar sind, zeigt die Backend-Schnittstelle.
Die Servermiete lässt sich direkt der Preisliste entnehmen; Wartezeiten und Fehlerkosten müssen Sie selbst erfassen. Protokollieren Sie die Zeit vom Commit bis zum Build-Start, die Ausführungsdauer, Fehlerursachen und manuelle Eingriffe. Beim Eigenkauf zählen auch die Ersteinrichtung, Systemupdates, Speicherbereinigung und Hardwarepflege. Setzen Sie diese Zeit nicht mit null an.
Da es sich nicht um eine virtuelle Maschine handelt, konkurrieren CPU, Unified Memory, Speicher und macOS einer Maschine nicht mit anderen Kunden. Das reduziert Ressourcenkonflikte zwischen Kunden, doch mehrere Aufgaben desselben Kunden können sich weiterhin gegenseitig ausbremsen.
Clean Builds, Linker und Simulatoren beanspruchen gleichzeitig CPU, Arbeitsspeicher und Speicherplatz. Ermitteln Sie zunächst mit einer Aufgabe einen Ausgangswert und erhöhen Sie dann schrittweise die Parallelität. Beobachten Sie Speicherdruck und Auslagerung, statt allein vom Chipnamen auf die Zahl möglicher Builds zu schließen.
Zertifikate und Profile verwalten Sie selbst; der Schlüsselbund wird nicht mit anderen Kunden geteilt. Planen Sie trotzdem Build-Benutzer, das Entsperren des Schlüsselbunds und Zugriffsrechte für private Schlüssel. So vermeiden Sie, dass parallele Aufgaben desselben Teams gleichzeitig die Signiereinstellungen ändern.
Die vollständige grafische macOS-Oberfläche und die Kommandozeile stehen zur Verfügung; mehrere Xcode-Versionen lassen sich verwenden. Legen Sie die Versionsauswahl in der Build-Aufgabe fest und trennen Sie Cache-Verzeichnisse nach Projekt. Prüfen Sie nach einem Toolchain-Upgrade Abhängigkeiten und Build-Ergebnisse erneut.
Die drei Tarife: XR Build 16 (M4 / 16GB / 256GB), XR Build 24 (M4 / 24GB / 512GB) und XR Build Pro 64 (M4 Pro / 64GB / 2TB). Testen Sie zunächst, ob die kleinste Konfiguration für Ihr Projekt ausreicht. Bei anhaltendem Speicherdruck, mehr Simulator-Kombinationen oder größeren Caches können Sie eine höhere Konfiguration prüfen. Die Wahl ist keine pauschale Formel für die Parallelität jedes Projekts.
Mieten ersetzt nicht jedes Gerät vor Ort. Prüfen Sie vor der Entscheidung, ob Ihr Team physischen Zugriff benötigt, bereits einen eingespielten Betrieb hat und dauerhaft mit stabiler Auslastung rechnen kann.
Wenn die Build-Auslastung langfristig stabil ist und Ihr Team Netzwerk, Strom, Fernverwaltung und eine zuständige Person hat, lohnt sich eine vollständige Kostenrechnung für den Kauf. Berücksichtigen Sie Anschaffung, laufende Kosten, Arbeitszeit und Ersatzgeräte bei einem Ausfall – nicht nur den Listenpreis der Hardware.
Für lokale Peripheriegeräte, Debugging vor Ort oder Aufgaben, bei denen Geräte direkt bedient werden müssen, ist ein lokaler Mac oft die einfachere Lösung. Builds und Archive können in die Cloud wandern, während Tests mit physischem Zugriff lokal bleiben. Sie müssen sich nicht auf einen einzigen Weg festlegen.
Wenn Quellcode und Build-Umgebung im Unternehmen bleiben müssen, klären Sie zunächst die Anforderungen an Datenverarbeitung und Netzwerkgrenzen. Ob ein Remote-Server infrage kommt, richtet sich nach den konkreten Vorgaben Ihres Teams. Ein exklusiver Server ersetzt weder interne Freigaben noch Richtlinien zum Datenmanagement.
Bei wenigen, kurzen Builds, die sich zustandslos neu erstellen lassen, kann ein gemeinsam genutzter Dienst den Aufwand für die eigene Umgebung senken – sofern Konfigurationen und Warteschlangenregeln für Sie passen. Prüfen Sie, ob die benötigte Xcode-Version, Signiermethode und Cache-Strategie unterstützt werden. „Sofort einsatzbereit“ sagt noch nichts über den gesamten Lebenszyklus eines Builds aus.
Vergleichen Sie keine Ergebnisse aus unterschiedlichen Commits, Xcode-Versionen oder Cache-Zuständen. Halten Sie die Eingaben konstant und messen Sie Wartezeit, Ausführung, Fehlerbehebung und manuelle Arbeit getrennt.
Verwenden Sie denselben Commit, dasselbe Scheme, dieselbe Build-Konfiguration und dieselbe Xcode-Version. Behalten Sie die Lockfiles bei, legen Sie fest, ob der Cache leer oder bereits befüllt ist, und erfassen Sie die Dauer für die Synchronisierung von Quellcode und Abhängigkeiten.
Führen Sie alles aus – vom Abruf des Quellcodes über die Installation der Abhängigkeiten und Tests bis hin zu Archive, Signierung und Artefakt-Export. Erfolgreiche Tests allein bedeuten noch keine erfolgreiche Veröffentlichung. Prüfen Sie das finale Artefakt, das Signierergebnis und die Build-Protokolle.
Erhöhen Sie die Zahl der Aufgaben schrittweise entsprechend dem Commit-Rhythmus Ihres Teams. Erfassen Sie Wartezeiten in der Warteschlange, Speicherdruck, freien Speicherplatz und fehlgeschlagene Wiederholungen. Entscheiden Sie dann, ob die aktuelle Konfiguration reicht oder Aufgaben auf mehrere Server verteilt werden sollten.
Planen Sie Zertifikatsupdates, Zugangsdatenverwaltung, Cache-Bereinigung und Datensicherungen. Prüfen Sie Verlängerung und Vorgehen bei Vertragsende, bevor Sie sich für Monats- oder Quartalszahlung entscheiden. Ein erfolgreicher Build allein belegt keinen dauerhaft stabilen Betrieb.
Bringen Sie Ihr Projekt, Scheme und Ihren Veröffentlichungsablauf mit. Prüfen Sie zuerst, ob sich ein Build erstellen lässt – danach entscheiden Sie über Konfiguration, Parallelität und Abrechnungszeitraum.
Drei Konfigurationen, sechs Standorte. Technische Daten und Preise für vier Abrechnungszeiträume finden Sie einzeln auf der Tarifseite.