Build-Umgebungen in Ihrer Hand

Wir konzentrieren uns auf eins:
Builds ohne Warteschlange

Dedizierte physische Mac mini geben iOS- und macOS-Teams die Kontrolle über Toolchain, Signierungsumgebung und Auftragsreihenfolge. Keine virtuellen Maschinen und keine Builds in der Warteschlange anderer Kunden.

Dedizierten Cloud-Mac mieten Modelle und Preise

Abrechnung pro Tag, Woche, Monat oder Quartal. Die aktuelle Verfügbarkeit sehen Sie direkt in der Konsole.

Ressourcen
1 Kunde pro Knoten
Modelle
3 Apple-Silicon-Konfigurationen
Standorte
6 Regionen zur Auswahl
Erst die Warteschlange lösen, dann automatisieren

Nach einem Merge sollte nicht erst der Build anderer Teams enden müssen

Ausgangspunkt für unseren Service waren zwei wiederkehrende Probleme in gemeinsam genutzten CI-Umgebungen: Teams haben keine Kontrolle über die Ausführungsressourcen, und Signierungsumgebungen lassen sich nur schwer voneinander trennen.

Wartezeit und Build getrennt betrachten

Nach einem Commit kann die Pipeline bereits auf einen Runner warten, bevor überhaupt kompiliert wird. Mit angepassten Skripten lassen sich Build-Schritte verkürzen – eine gemeinsam genutzte Warteschlange wird dadurch aber nicht exklusiv für Ihr Projekt. So ist oft unklar, ob der Build tatsächlich langsamer ist oder der Job noch auf Ressourcen wartet.

Deshalb weisen wir einen vollständigen physischen Knoten einem einzelnen Kunden zu. Ihr Runner kann auf bestimmte Projekte beschränkt werden. Job-Tags, Auslöser und Reihenfolge legen Sie selbst fest. Jobs anderer Kunden gelangen nicht in die Build-Warteschlange dieses Rechners.

Ein dedizierter Knoten verhindert Ressourcenkonflikte zwischen Kunden. Die Parallelität Ihrer Projekte auf demselben Knoten müssen Sie weiterhin sinnvoll steuern.

Signierungsumgebung ans Team binden

Zertifikate, Profile, Schlüsselbund, Xcode-Pfad und Dependency-Cache bilden zusammen Ihre Build-Umgebung. Eine Bereinigung oder Versionsänderung in einer gemeinsam genutzten Umgebung kann dazu führen, dass ein zuvor reproduzierbares Archive fehlschlägt und manuell untersucht werden muss.

Auf einem dedizierten Knoten kann Ihr Team eigene Verzeichnisstrukturen, Berechtigungen und Toolchain-Konventionen festlegen. Fixieren Sie die Xcode-Version, trennen Sie Test- und Release-Jobs und dokumentieren Sie die Signierungskonfiguration. Anschließend können Sie diese Regeln in Ihrer Pipeline abbilden. Die Umgebung bleibt nachvollziehbar und lässt sich prüfen und wiederherstellen, statt eine undurchsichtige Einmallösung zu sein.

Ein dedizierter Knoten ersetzt keine Backups. Ihr Team sollte Quellcode, Signierungsmaterial und Build-Artefakte weiterhin separat sichern.

„Keine Warteschlange“ bedeutet hier, dass Sie nicht auf die Nutzung Ihres Knotens durch andere Kunden warten müssen. Es ist keine Zusage, dass beliebig viele Jobs gleichzeitig abgeschlossen werden. Die Build-Geschwindigkeit hängt weiterhin von Projektgröße, Dependency-Downloads, Speicherauslastung und Parallelität ab. Testen Sie zuerst mit Ihrem eigenen Projekt und wählen Sie danach Konfiguration und Mietdauer.

Klare Serviceprinzipien

Klare Fakten sind wichtiger als große Versprechen

Wir beschreiben unseren Service anhand der Ressourcenzuweisung, der verfügbaren Konfigurationen und ihrer Preise. Die folgenden drei Prinzipien gelten sowohl für kurzfristige Tests als auch für Build-Knoten im Dauereinsatz.

Dediziert, ohne Überbuchung

Ein physischer Knoten wird genau einem Kunden zugewiesen. CPU, Unified Memory und lokaler Speicher werden nicht mit anderen Kunden geteilt und auch nicht durch Aufteilung in virtuelle Maschinen mehrfach vergeben.

Sie können mehrere Projekte ausführen, müssen die Parallelität der Jobs aber selbst steuern. Legen Sie zunächst eine Referenz mit einem einzelnen Job fest, erhöhen Sie dann schrittweise die Runner-Parallelität und beobachten Sie Speicher, Festplatte und Stabilität der Build-Artefakte.

So prüfen Sie es: erst die exklusive Nutzung des gesamten Rechners bestätigen, dann die eigene Parallelität bewerten.

Preise für jede Konfiguration

Für alle drei Konfigurationen sind Tages-, Wochen-, Monats- und Quartalspreise angegeben. Der Einstieg ist XR Build 16 für $21.7/Tag. Bei längerer Nutzung gilt der Preis des jeweiligen Abrechnungszeitraums – rechnen Sie nicht einfach den Kurzzeitpreis hoch.

Speichererweiterungen und Thunderbolt-5-Parallelbetrieb sind separat ausgewiesen. Vergleichen Sie die Knotenmiete getrennt von optionalen Zusatzleistungen und prüfen Sie die Konfigurationsdetails vor der Zahlung.

Alle Preise ansehen

Konkrete statt übertriebene Spezifikationen

Im Angebot stehen ausschließlich diese drei Konfigurationen: M4 / 16GB / 256GB, M4 / 24GB / 512GB und M4 Pro / 64GB / 2TB. Ein Modellname ersetzt keine Angaben zu Chip, Arbeitsspeicher und Speicherplatz.

Beispielhafte Laufzeiten sind keine Leistungszusage für Ihr Projekt. Halten Sie bei Tests Cold Builds, inkrementelle Builds und Archives fest – bei identischer Code- und Xcode-Version sowie denselben Cache-Bedingungen.

So vergleichen Sie aussagekräftig: dasselbe Projekt unter denselben Bedingungen testen.

Mit einem Tagesprojekt starten

Vier Workflows, dieselbe dedizierte Umgebung

Die folgenden Beispiele orientieren sich an typischen Nutzerrollen. Es sind weder Kundenberichte noch Performance-Messungen. Jeder Workflow zeigt zuerst die Aufgaben und nennt anschließend ein Modell, das sich dafür testen lässt.

Solo-Entwicklung: Feature fertigstellen, Build erstellen

Tagsüber entwickeln Sie SwiftUI lokal und testen die Interaktionen. Nach dem Commit ruft der Cloud-Knoten den gewünschten Branch ab, löst Dependencies auf, führt Tests und xcodebuild archive aus und exportiert anschließend die signierten Artefakte. Der Upload zu TestFlight erfolgt nach dem Prozess Ihres Teams.

Starten Sie mit einer einzelnen App und wenigen parallelen Jobs und testen Sie zunächst XR Build 16. Bewahren Sie Release-Skript und Fehlerprotokolle auf, damit Sie am nächsten Tag nicht erneut über die Umgebung rätseln müssen.

XR Build 16 · M4 / 16GB / 256GB

XR Build 16 mieten

CI-Team: Merge Requests an Runner anbinden

Prüfen Sie morgens die Fehlerprotokolle des letzten Laufs. Nach einem Merge am Nachmittag startet automatisch ein GitHub- oder GitLab-self-hosted-Runner. Trennen Sie Unit-Tests und Release-Jobs anhand von Tags. Mit Fastlane gym steuern Sie die Build-Schritte und halten die Signierung für App, Widget und Extension einheitlich.

Bei mehreren Targets sowie gleichzeitigen Tests und Cache-Zugriffen empfiehlt sich ein Test mit XR Build 24. Erhöhen Sie die Parallelität schrittweise, damit nicht mehrere Archives gleichzeitig in dasselbe Ausgabeverzeichnis schreiben oder um den Signierungsstatus konkurrieren.

XR Build 24 · M4 / 24GB / 512GB

XR Build 24 mieten

KI-Experimente: Modelle und Builds zeitlich trennen

Testen Sie vormittags die Inferenz eines kleinen Modells mit MLX und dokumentieren Sie Modell, Quantisierung und Speicherbedarf. Probieren Sie nachmittags Fine-Tuning aus, sichern Sie Checkpoints und testen Sie bei Bedarf den Export nach Core ML. Wenn nachts Builds laufen sollen, beenden Sie zuvor die Experimente oder begrenzen Sie die Parallelität.

Für solche Aufgaben können Sie mit XR Build Pro 64 starten. 64GB Unified Memory sind eine konkrete Konfiguration, aber keine Garantie, dass jedes Modell darauf läuft. Kalkulieren Sie zuerst den Gesamtbedarf von Modell, Laufzeitumgebung und weiteren Jobs.

XR Build Pro 64 · M4 Pro / 64GB / 2TB

XR Build Pro 64 mieten

Audio und Video: Jobs auslagern, nicht das einzige Backup

Prüfen Sie tagsüber in der macOS-Oberfläche Projekt- und Medienpfade sowie Softwarelizenzen, Plugins und Schriften für Logic oder Final Cut. Planen Sie Renderings oder Batch-Transkodierungen für die Nacht. Exportieren Sie anschließend das fertige Material, prüfen Sie die Dateien und löschen Sie temporäre Caches.

Für größere Projekte lässt sich XR Build Pro 64 testen. Originalmaterial und fertige Dateien sollten jedoch zusätzlich an einem anderen Ort gesichert sein. Die Arbeit per Fernzugriff hängt von Ihrem lokalen Netzwerk und der Entfernung zum Knoten ab. Testen Sie vor der Migration mit echten Medien und Ihrer tatsächlichen Verbindung.

XR Build Pro 64 · M4 Pro / 64GB / 2TB

XR Build Pro 64 mieten
Ein Angebot, sechs Standorte

Standort wählen, Toolchain und Bereitstellung prüfen

Alle Modelle sind Mac mini mit Apple Silicon. Drei Konfigurationen sind an allen sechs Standorten verfügbar. Wählen Sie zunächst passend zu Arbeitszeiten und Netzwerkbedingungen Ihres Teams. Testen Sie anschließend den Fernzugriff selbst: Eine ähnliche Zeitzone bedeutet nicht automatisch eine geringere Netzwerklatenz.

Singapur

SG · UTC+8

Geeignet für Teams in Südostasien, die tagsüber zusammenarbeiten und Jobs über Nacht ausführen. Prüfen Sie vor der Migration den tatsächlichen Zugriff auf Quellcode-Repositories und Dependency-Quellen.

Verfügbar

Japan · Tokio

JP · UTC+9

Geeignet für Teams, deren Zusammenarbeit sich an japanischen Arbeitszeiten orientiert. Hinterlegen Sie die Zeitzone für Release-Jobs ausdrücklich in der CI-Konfiguration, damit Zeitpläne nicht von lokalen Standardwerten abhängen.

Verfügbar

Südkorea · Seoul

KR · UTC+9

Geeignet für Teams in Südkorea und Nordostasien, die Build-Protokolle und Artefakte prüfen. Testen Sie beim Fernzugriff sowohl die Texteingabe als auch die Dateiübertragung.

Verfügbar

Hongkong

HK · UTC+8

Geeignet für die Zusammenarbeit während der Arbeitszeiten in Südchina und Südostasien. Prüfen Sie beim regionsübergreifenden Zugriff auf Repositories sowohl die Verbindungsstabilität als auch den Dependency-Download.

Verfügbar

US-Ostküste

US-E · UTC−5 / UTC−4

Geeignet für Teams im Osten Nordamerikas und zur Abstimmung mit westeuropäischen Arbeitszeiten. Durch die Sommerzeit ändert sich der lokale UTC-Versatz. Geben Sie für geplante Jobs daher am besten eine Zeitzone explizit an.

Verfügbar

US-Westküste

US-W · UTC−8 / UTC−7

Geeignet für Teams an der nordamerikanischen Westküste, die gemeinsam Fehler untersuchen und Releases erstellen. Bewahren Sie bei der Zusammenarbeit über Zeitzonen hinweg den UTC-Versatz in Protokollen auf, damit die Reihenfolge von Jobs nachvollziehbar bleibt.

Verfügbar

Die angezeigten Status beziehen sich auf das aktuelle Angebot. Maßgeblich ist die Verfügbarkeit zum Bestellzeitpunkt, wie sie die Konsole live anzeigt. Die Knoten sind an 365 Tagen im Jahr regulär in Betrieb. Bei Hardwareproblemen greift unser Fehlerbehebungsprozess.

Betrieb: Bereitstellung, Prüfung und Fehlerbehebung

Hardwareprobleme sollen nicht in Build-Protokollen untergehen. Bei der Bereitstellung prüfen wir die Umgebung. Im laufenden Betrieb unterscheiden wir zwischen Anwendungs- und Knotenfehlern. Bei Hardwarearbeiten klären wir zuerst, welche Daten betroffen sind und wie die Wiederherstellung abläuft.

  1. Bereitstellung und Übergabe

    Wir prüfen Chip, Arbeitsspeicher, Festplatte und Standortangaben und richten macOS und Xcode ein. Nach der Zuweisung finden Sie SSH- und Fernzugriffsdaten in der Konsole. Prüfen Sie im Team zusätzlich Administratorrechte, Xcode-Pfad und Projekt-Dependencies. Führen Sie einen kleinen Testjob aus, bevor Sie Ihre produktive Pipeline migrieren.

  2. Regelmäßige Prüfung und Fehleranalyse

    Auf Knotenseite prüfen wir die Erreichbarkeit und den Hardwarebetrieb. Ihr Team behält freien Speicherplatz, wachsende Caches und fehlgeschlagene Jobs im Blick. Melden Sie Probleme über ein Support-Ticket in der Konsole und geben Sie Standort, Modell, Zeitpunkt und Fehlermeldung an. So lassen sich Netzwerk-, Toolchain-, Signierungs- und Hardwareprobleme voneinander abgrenzen, statt jeden Fehler pauschal der Build-Leistung zuzuschreiben.

  3. Hardwaremaßnahmen und Wiederherstellung

    Bestätigen wir ein Hardwareproblem, koordinieren wir die Bearbeitung oder den Austausch des Knotens über ein Support-Ticket. Dabei teilen wir mit, ob sich die Verbindungsdaten ändern und welche Inhalte neu eingerichtet werden müssen. Ihr Team stellt Quellcode, Dependencies und Signierungsumgebung aus Backups wieder her und prüft anschließend Toolchain-Version und Build. Ein Hardwareaustausch ist kein Datenbackup. Ein Artefakt, das nicht überprüft wurde, gilt auch nicht als Nachweis einer erfolgreichen Wiederherstellung.

In der Konsole anmelden und Ticket erstellen

Finden Sie die passende Konfiguration

Vergleichen Sie zuerst Chip, Arbeitsspeicher, Festplatte und Abrechnungszeitraum. Testen Sie anschließend mit Ihrem eigenen Projekt. Ein reproduzierbares Archive ist ein guter Ausgangspunkt für den Umstieg Ihrer Build-Pipeline.

Zahlung nur mit USDT-TRC20 oder Visa / Mastercard / Amex (über Stripe); Abrechnung in US-Dollar. Welche Zahlungsoptionen verfügbar sind, zeigt die Backend-Schnittstelle an.

Drei Mietpläne ansehen Cloud-Mac mieten