Erst Ausstattung prüfen, dann Builds planen

3 Modelle,
Preise passend zu Ihrem Build-Rhythmus

Alle Angebote umfassen einen dedizierten Mac mini, keine virtuelle Maschine. Alle 6 Standorte sind buchbar. Abrechnung pro Tag, Woche, Monat oder Quartal. Die aktuelle Verfügbarkeit sehen Sie im Dashboard.

Ab $21.7/Tag testen Sie Ihr Projekt. Der gesamte physische Rechner ist einem einzigen Kunden vorbehalten – mit vollem Zugriff auf macOS-Oberfläche und Kommandozeile.

Gleiche Ausstattung, vier Laufzeiten

Erst Laufzeit wählen, dann Modell vergleichen

Der Laufzeitwechsel aktualisiert nur die angezeigten Preise der drei Tarife. Chip, Arbeitsspeicher und SSD bleiben unverändert. Die Preistabelle zeigt weiterhin alle vier Laufzeiten zur Budgetplanung.

Die angezeigten Preise gelten pro Tag. Abrechnung in US-Dollar.

Für erste Builds einer einzelnen App

XR Build 16

M4 16 GB RAM 256 GB SSD

$21.7/Tag

Verlagern Sie Archive und Release-Skripte einer einzelnen App auf einen dedizierten Rechner. Testen Sie zuerst einen vollständigen Clean Build und prüfen Sie anschließend inkrementelle Builds und Signierung. So sehen Sie, ob Ihr Projekt zuverlässig Artefakte erzeugt.

  • Für erste Tests mit einer App und mehreren Builds pro Tag.
  • 256 GB SSD für Quellcode, Abhängigkeiten und Build-Ausgaben. Alte Archive müssen regelmäßig gelöscht werden.
  • Dedizierter physischer Rechner mit vorinstalliertem macOS und Xcode; Zugangsdaten werden bereitgestellt.
Mehrere Targets und Tests

XR Build 24

M4 24 GB RAM 512 GB SSD

$40.8/Tag

Mehr Arbeitsspeicher und Cache-Platz für Haupt-App, Widgets und Extensions. Integrieren Sie UI-Tests in Ihre Pipeline und ermitteln Sie mit Ihren eigenen Aufgaben die passende Ausführungsreihenfolge.

  • Für Projekte mit mehreren Targets, vielen Abhängigkeiten oder UI-Tests.
  • 512 GB SSD bieten mehr Platz für Dependency-Caches, Simulatoren und Build-Artefakte.
  • Legen Sie die Parallelität anhand des tatsächlichen Speicherbedarfs fest, statt unbegrenzt viele Aufgaben zu starten.
Parallele Aufgaben und große Caches

XR Build Pro 64

M4 Pro 64 GB RAM 2 TB SSD

$59.5/Tag

Mehr Ressourcen für parallele Simulator-Matrizen, MLX-Experimente und große Caches. Wenn Builds und Experimente denselben Rechner nutzen, priorisieren und planen Sie die Aufgaben, statt alle Ressourcen gleichzeitig voll auszulasten.

  • Für speicherintensive Aufgaben und große Mengen aufzubewahrender Build-Artefakte.
  • 64 GB Unified Memory und 2 TB SSD – klar ausgewiesene Ausstattung ohne virtuelle Kontingente.
  • Bestimmen Sie die Parallelität anhand von Messungen mit Ihrem Projekt. Die Speicherkapazität entspricht nicht automatisch einer bestimmten Anzahl von Aufgaben.

Alle Laufzeiten und Ausstattungen im Vergleich

Die Beträge gelten jeweils für die angegebene Laufzeit und sind keine auf Tagespreise umgerechneten Werte. Prüfen Sie vor einer längeren Laufzeit, ob Abhängigkeiten, Signierung und Build-Skripte auf dem Rechner funktionieren.

3 Modelle · Preise in US-Dollar · Tag / Woche / Monat / Quartal
Modell Chip / RAM / SSD Tag Woche Monat Quartal
XR Build 16 M4 / 16 GB / 256 GB $21.7 $58.5 $108.3 $294.6
XR Build 24 M4 / 24 GB / 512 GB $40.8 $110.2 $204.1 $555.2
XR Build Pro 64 M4 Pro / 64 GB / 2 TB $59.5 $160.5 $297.3 $808.7
Tarif nach Engpass wählen, nicht nach Projektnamen

Einen vollständigen Build als Maßstab nehmen

Bei einer App mit mehreren Builds pro Tag testen Sie XR Build 16. Für mehrere Targets, Widgets, Extensions und UI-Tests ist XR Build 24 eine gute Wahl. Bei parallelen Simulator-Matrizen, MLX-Experimenten oder großen Caches kommt XR Build Pro 64 infrage. Diese Empfehlungen sind ein Ausgangspunkt – maßgeblich sind die Messwerte Ihres Projekts.

  1. 01

    Zuerst den RAM-Spitzenbedarf messen

    Führen Sie Installation der Abhängigkeiten, Kompilierung, Archive und Tests einzeln aus. Achten Sie auf anhaltenden Speicherdruck und entscheiden Sie dann, ob mehr RAM oder weniger parallele Aufgaben sinnvoll sind. Der Leerlaufverbrauch allein sagt wenig aus.

  2. 02

    Dann den Speicherbedarf erfassen

    Erfassen Sie Quellcode, Dependency-Caches, DerivedData, Simulatoren und Archive getrennt. Legen Sie fest, wie viele Artefakte aufbewahrt werden sollen, und lassen Sie Platz für temporäre Build-Ausgaben. So erkennen Sie, ob eine SSD-Erweiterung nötig ist.

  3. 03

    Zum Schluss Konflikte zwischen Aufgaben prüfen

    Erhöhen Sie die Parallelität schrittweise ausgehend von seriellen Abläufen. Vergleichen Sie die Dauer einzelner Aufgaben mit dem Gesamtdurchsatz. Schreiben zwei Aufgaben in dasselbe Ausgabeverzeichnis oder verwenden sie gemeinsam einen veränderlichen Cache, trennen Sie zuerst Verzeichnisse und Skripte, bevor Sie weitere Ressourcen hinzufügen.

Ein dedizierter Rechner verhindert, dass andere Kunden dieselben physischen Ressourcen nutzen. Mehrere Aufgaben, die Sie auf demselben Rechner starten, teilen sich weiterhin Chip, Arbeitsspeicher und SSD.

Erst Kapazität, dann Anschlussart prüfen

Cache- und Artefaktspeicher separat planen

SSD-Erweiterungen sind optional und ersetzen nicht die Basisausstattung der drei Tarife. Thunderbolt 5-Verbund wird pro Rechner berechnet und führt weder zu automatisch zusammengelegtem Arbeitsspeicher noch zur automatischen Verteilung von Builds. Die tatsächlich verfügbaren Konfigurationen sehen Sie im Bestellprozess.

Listenpreise der Erweiterungen · Abrechnung in US-Dollar · separat zum gewählten Tarif prüfen
Erweiterung Tag Woche Monat Quartal
+1 TB SSD $2.8 $7.7 $14.2 $38.6
+2 TB SSD $5.6 $15.4 $28.4 $77.2
Thunderbolt 5-Verbund (pro Rechner) $1.8 $5 $9.2 $25

Mehr Speicherplatz ersetzt kein Backup

Mehr Speicherplatz bietet Raum für zusätzliche Caches und Artefakte, ersetzt aber kein separates Backup. Speichern Sie den Quellcode in der Versionsverwaltung und sichern Sie Release-Artefakte sowie erforderliche Signierungsunterlagen an einem von Ihnen kontrollierten Ort. Prüfen Sie, ob sich die Daten wiederherstellen lassen.

Erst aufräumen, dann erweitern

Dependency-Caches lassen sich neu erstellen; für Release-Artefakte brauchen Sie eine Aufbewahrungsregel. Löschen Sie nicht mehr benötigte Archive und Simulatoren und prüfen Sie nach einem Build den freien Speicherplatz. Erweitern Sie nur für Daten, die Sie tatsächlich behalten müssen.

Alle 3 Tarife an 6 Standorten

Standort nach Teamnähe, Modell nach Auslastung wählen

Alle drei Modelle sind in Singapur, Tokio, Seoul, Hongkong, den US-Ostküsten- und US-Westküsten-Standorten verfügbar. Die folgende Tabelle zeigt das Angebot; alle Kombinationen sind als gut verfügbar gekennzeichnet. Die aktuelle Verfügbarkeit sehen Sie im Dashboard.

3 Modelle × 6 Standorte · alle aufgeführten Kombinationen buchbar
Modell Singapur Tokio, Japan Seoul, Südkorea Hongkong US-Ostküste US-Westküste
XR Build 16 Gut verfügbar Gut verfügbar Gut verfügbar Gut verfügbar Gut verfügbar Gut verfügbar
XR Build 24 Gut verfügbar Gut verfügbar Gut verfügbar Gut verfügbar Gut verfügbar Gut verfügbar
XR Build Pro 64 Gut verfügbar Gut verfügbar Gut verfügbar Gut verfügbar Gut verfügbar Gut verfügbar

Viele interaktive Aufgaben: Testen Sie zuerst einen Standort in der Nähe der Team-Infrastruktur. Prüfen Sie Remote-Desktop, Quellcode-Synchronisierung und Artefakt-Downloads. Die geografische Entfernung ist nur ein erster Anhaltspunkt – entscheidend sind auch Ihr lokales Netzwerk und das tatsächliche Routing.

Viele automatisierte Builds: Berücksichtigen Sie den Standort des Code-Repositorys, der Quellen für Abhängigkeiten und des Artefakt-Ziels. Unbeaufsichtigte Aufgaben benötigen keine dauerhafte Desktop-Nutzung. Prüfen Sie trotzdem Wiederholungen bei fehlgeschlagenen Downloads, die Verbindungsstabilität und die Übertragung der Logs.

Zusammenarbeit über Zeitzonen hinweg: Legen Sie zuerst Regeln für Build-Auslöser und die Zeitzone der Logs fest, bevor Sie den Standort wählen. Die Rechner laufen an 365 Tagen im Jahr. Die Arbeitszeiten Ihres Teams bestimmen nicht die Laufzeit des Rechners.

Bestelldetails vor der Zahlung prüfen

In US-Dollar zahlen, Zahlungen und Verlängerungen im Dashboard verwalten

Wählen Sie Modell, Laufzeit, Standort und Erweiterungen und prüfen Sie dann den aktuellen Bestellbetrag. Der Laufzeitwechsel in den Tarifkarten zeigt nur eine Preisvorschau. Maßgeblich sind die Angaben im Bestellprozess.

Kartenzahlung

Visa, Mastercard und Amex werden über Stripe in US-Dollar (USD) abgerechnet. Welche Zahlungsoptionen tatsächlich verfügbar sind, hängt von der Rückmeldung des Zahlungsdienstes ab. Prüfen Sie vor der Zahlung Betrag und Bestellung auf der Zahlungsseite.

USDT-TRC20

Zahlung mit USDT-TRC20 möglich. Prüfen Sie vor der Zahlung Netzwerk, Empfängerangaben und Betrag anhand der Zahlungsseite. Verwenden Sie nicht die Zahlungsdaten einer früheren Bestellung für eine neue Bestellung.

Verlängerung und Tarifwechsel

Prüfen Sie im Dashboard die aktuelle Laufzeit und veranlassen Sie vor deren Ende eine Verlängerung oder einen Tarifwechsel. Sichern Sie bei einem Modellwechsel zuerst Ihr Projekt und wichtige Unterlagen und folgen Sie dann dem Ablauf im Dashboard.

Zahlungsfragen und Build-Probleme getrennt melden

Für Zahlungsfragen benötigen wir Bestellnummer, gewählte Laufzeit und Zahlungsmethode. Für die Analyse eines Builds nennen Sie bitte Standort, Modell, Xcode-Version und Fehler-Logs. Kunden mit bestehender Miete können sich im Dashboard anmelden und ein Ticket einreichen. Fragen vor der Bestellung und sonstige Anliegen senden Sie an support@xcoderent.com. Senden Sie keine vollständigen Verbindungskennwörter, privaten Schlüssel oder ungeschwärzten Zertifikatsunterlagen.

Von der Bestellung zum ersten Artefakt

Nach der Bereitstellung zuerst eine minimale Pipeline ausführen

Bestellung, Zuweisung eines Rechners und Zugangsdaten sind drei getrennte Schritte. Eine feste Bereitstellungsdauer wird nicht zugesagt. Maßgeblich sind Bestell- und Instanzstatus im Dashboard; Beispielwerte zur Build-Dauer sind keine Bereitstellungszusage.

  1. 01

    Bestellen und bezahlen

    Wählen Sie Modell, Laufzeit und Standort und fügen Sie bei Bedarf Erweiterungen hinzu. Prüfen Sie Ausstattung und Betrag, bevor Sie bezahlen. Notieren Sie die Bestellnummer, um den Bestellstatus später im Dashboard zu prüfen.

  2. 02

    Rechner zuweisen und vorbereiten

    Nach Eingang der Bestellung in den Bereitstellungsprozess wird ein dedizierter physischer Rechner zugewiesen und mit macOS und Xcode vorbereitet. Prüfen Sie die benötigten Versionen der Toolchain. Projektabhängigkeiten, Build-Skripte und Konfiguration richten Sie nach Ihren Anforderungen ein.

  3. 03

    SSH- und VNC-Zugangsdaten abrufen

    Rufen Sie die Verbindungsdaten im Dashboard ab und prüfen Sie Instanz und gewählten Standort. Führen Sie Automatisierungen über SSH aus und kontrollieren Sie Signierung und Toolchain über die macOS-Oberfläche. Erstellen Sie anschließend ein vollständiges Archive, um die Artefakte zu prüfen.

Bei der Abnahme vier Angaben festhalten

Notieren Sie Xcode-Version, Lockfile der Abhängigkeiten, Build-Befehl und Ausgabepfad. Führen Sie mit demselben Quellcode und derselben Signierungskonfiguration einen Clean Build und einen inkrementellen Build aus und speichern Sie die vollständigen Logs. Registrieren Sie erst dann einen Self-Hosted Runner, aktivieren Sie zeitgesteuerte Aufgaben oder erhöhen Sie die Parallelität, wenn die Artefakte geprüft sind.

Ein dedizierter Rechner behebt keine Konflikte zwischen den Abhängigkeiten Ihres Projekts. Schlägt der erste Build fehl, unterscheiden Sie zunächst zwischen Netzwerk-Downloads, Toolchain-Version, Signierung und Kompilierung. Vermeiden Sie wiederholte Versuche, bei denen Sie sämtliche Caches löschen.

Ausstattung geklärt? Jetzt Ihr Projekt testen

Tarif wählen und Rechner im Dashboard starten

Mieten Sie zunächst für einen Tag und führen Sie einen vollständigen Build, Tests und ein Archive aus. Wenn ausreichend Ressourcen verfügbar sind, wählen Sie für eine stabile Build-Warteschlange die passende Laufzeit.