Warum wir uns dafür entschieden haben

iOS-Builds sollten zuverlässig auf einem echten Mac laufen

ArmRDP stellt Ihnen einen vollständigen Mac mini bereit. Der physische Rechner ist exklusiv für Sie reserviert – keine virtuelle Maschine. Mit einer festgelegten Toolchain läuft jeder Build in einer nachvollziehbaren Umgebung.

Der Grund für unseren Service ist einfach: Entwickler brauchen nicht noch mehr unterschiedliche Umgebungen, sondern einen Mac, der nicht mit der täglichen Entwicklungsarbeit geteilt werden muss und Aufgaben zuverlässig ausführt. Archivierung, Codesign, Export und Runner sollten in derselben kontrollierten Umgebung bleiben. So müssen Sie kurz vor einem Release nicht erst herausfinden, welche Toolchain geändert wurde.

Cloud-Mac mieten Modelle & Preise

Ab einem Tag, ab $21.1/Tag. Ob ein Rechner verfügbar ist, sehen Sie live in der Konsole.

Ein ganzer Rechner

Exklusiv – mehr als nur ein Ressourcen-Label

Eine kontrollierbare Build-Umgebung beginnt mit klaren Grenzen bei den Ressourcen. Wir teilen einen Mac weder auf mehrere Mieter auf noch ersetzen wir den physischen Rechner durch eine virtuelle Maschine.

Keine gemeinsam genutzten Rechner

Während Ihrer Mietzeit steht der gesamte Mac mini nur Ihnen zur Verfügung. Unified Memory, SSD und Prozessor gehören zu diesem Rechner – es handelt sich nicht um zugewiesene Anteile eines gemeinsam genutzten Hosts.

Das bedeutet nicht, dass alle Aufgaben gleichzeitig gestartet werden sollten. Parallele Builds konkurrieren weiterhin um den Arbeitsspeicher und Speicherplatz des Rechners. Legen Sie die Zahl paralleler Runner anhand von Messungen in Ihrem Projekt fest.

Klare Grenzen bei physischen Ressourcen

Nativ ausführen, ohne Virtualisierungsschicht

Xcode, Simulator und Metal laufen auf einem physischen macOS-Rechner. Die grafische Oberfläche eignet sich zur Analyse interaktiver Probleme, die Kommandozeile für Archivierung, Signierung und Automatisierung.

Wir stellen die Laufzeitumgebung bereit, garantieren aber keine feste Build-Geschwindigkeit für bestimmte Projekte. Dauer und Ergebnis hängen unter anderem von Downloads, Cache-Treffern und dem Umfang der Tests ab.

Keine virtuelle Maschine

Änderungen nachvollziehbar halten

Sie können Ihre Xcode-Version auswählen und fixieren und den Rechner als selbst gehosteten Runner für GitLab oder GitHub Actions registrieren. So wird in der Pipeline eindeutig festgelegt, welche Umgebung zum Einsatz kommt.

Dokumentieren Sie am besten gemeinsam die Xcode-Version, Lockfiles, Runner-Tags und Build-Parameter. Prüfen Sie Upgrades zuerst und stellen Sie erst danach Produktionsaufgaben um – nicht mitten in einem Release.

Das Team kontrolliert die Umgebung

Standorte

5 Standorte für kurze Wege und passende Workflows

Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und der Westen der USA. Die Standorte bieten Teams in verschiedenen Regionen eine Option in ihrer Nähe. Außerdem kann der Runner näher an den Code- und Artefakt-Diensten Ihres Projekts stehen.

SG · UTC+8

Singapur

Für die Zusammenarbeit in Südostasien. Ideal für Teams, die manuelles Debugging und automatisierte Builds auf demselben Rechner ausführen möchten.

Prüfen Sie vor der Auswahl, wo Ihr Repository und Ihre Artefakte gespeichert sind.

JP · UTC+9

Japan (Tokio)

Für Teams in Ostasien. Xcode und Simulator lassen sich während der lokalen Arbeitszeiten bequem remote prüfen.

Prüfen Sie die Qualität der grafischen Verbindung mit Ihrem tatsächlichen Netzwerk.

KR · UTC+9

Südkorea (Seoul)

Für die Zusammenarbeit in Nordostasien. Eine regionale Option für Entwicklung, Signaturprüfungen und das Debugging von Runnern.

Terminalzugriff und Build-Warteschlangen sollten getrennt bewertet werden.

HK · UTC+8

Hongkong

Für Teams in Südchina und Südostasien. Geeignet für Workflows, in denen die Build-Umgebung häufig per Bildschirmfreigabe geprüft wird.

Die Nähe ist ein guter Ausgangspunkt, ersetzt aber keinen Verbindungstest.

US-W · UTC−8 / −7

Westen der USA

Für die Zusammenarbeit an der US-Westküste. Berücksichtigen Sie bei der Auswahl auch Repository, Paketquellen und Upload-Wege für Artefakte.

Die lokale Zeitzone ändert sich mit der Sommerzeit.

Bei der Standortwahl zwei Verbindungen berücksichtigen

Erstens die Verbindung von Ihnen zum Host, die sich auf die Bedienung über VNC auswirkt. Zweitens die Verbindung des Hosts zu Repository, Paketquellen und Artefaktspeicher, die Downloads und Uploads beeinflusst. Wenn Sie hauptsächlich automatisierte Builds ausführen, sollte nicht allein das Gefühl bei der Desktop-Verbindung über den Standort entscheiden. Alle drei Rechnerkonfigurationen sind an diesen 5 Standorten verfügbar. Die vollständigen technischen Daten und die Verfügbarkeit finden Sie auf der Angebotsseite.

Verfügbarkeitszusage

Klare Zahlen, klar geregelte Abwicklung

Alle Standorte sind an 365 Tagen im Jahr in Betrieb. Im Folgenden finden Sie Serviceziel und Regeln für Gutschriften – keinen historischen Monitoring-Bericht und keine Garantie für den Erfolg eines einzelnen Builds.

Zugesagte monatliche Verfügbarkeit

99.9%

Bei 30 Tagen entspricht das etwa 43 Minuten Ausfallzeit

30 × 24 × 60 × 0.1% = 43.2 Minuten

Bei Überschreitung gibt es eine Zeitgutschrift

Ausfallzeiten oberhalb des Kontingents werden in eine entsprechende Servicegutschrift umgerechnet. Bei einem Antrag unterscheiden Sie bitte zwischen einem nicht verfügbaren Rechner, eigenen Bedienfehlern und fehlgeschlagenen Projekt-Builds. Compilerfehler sowie Probleme mit Zertifikaten oder Abhängigkeiten gelten nicht automatisch als Ausfall des Rechners.

Antrag innerhalb von 7 Tagen stellen

Melden Sie sich in der Konsole an und erstellen Sie ein Support-Ticket. Geben Sie die Rechnernummer, den betroffenen Zeitraum und die Zeitzone an und fügen Sie Verbindungsfehler oder Aufgabenprotokolle hinzu. Bewahren Sie die Originaldaten auf, damit der Service für denselben Zeitraum geprüft werden kann.

Höhere Gewalt, eigenes Nutzerverhalten sowie Antrags- und Gutschriftenregeln richten sich nach den Servicebedingungen.

Support-Ticket in der Konsole erstellen Servicebedingungen ansehen

Daten & Trennung

Exklusiv während der Mietzeit – keine Daten für den nächsten Mieter

Wir greifen nicht auf Dateien oder Code der Nutzer auf gemieteten Rechnern zu und analysieren sie nicht. Ein exklusiver physischer Rechner schafft eine klare Trennung zwischen Mietern. Ihr Team muss Zugangsdaten, Backups und CI-Berechtigungen dennoch selbst verwalten – physische Trennung ersetzt diese Maßnahmen nicht.

Vor Mietende exportieren

Sichern Sie Codeänderungen, Build-Artefakte und Konfigurationen, die Sie behalten möchten, auf einem Speicher Ihres Teams. Nutzen Sie den gemieteten Rechner nicht als einzige Kopie. Caches lassen sich neu erstellen; nicht eingecheckte Arbeit und Signaturmaterial müssen Sie selbst sichern.
Daten nach Mietende löschen

Nach Mietende wird der Rechner gelöscht und die Umgebung zurückgesetzt. Nutzerdaten aus der vorherigen Mietzeit werden nicht als Umgebung für die nächste Bereitstellung aufbewahrt. Der nächste Mieter erhält keinen Zugriff auf Ihr Arbeitsverzeichnis.
Vor der erneuten Bereitstellung prüfen

Nach dem Löschen und Zurücksetzen der Umgebung wird der Rechner für die nächste Bereitstellung vorbereitet. Entfernen Sie außerdem alte Runner-Registrierungen und Zugriffstoken aus Ihrer CI-Plattform und wechseln Sie Zugangsdaten, die auf dem Rechner verwendet wurden. Externe Berechtigungen werden nicht durch das Löschen der Festplatte widerrufen.

Tickets nur mit den nötigen Informationen ergänzen

Rechnernummer, Zeitraum, Fehlermeldung und Schritte zur Reproduktion sind meist hilfreicher als ein vollständiges Projekt. Entfernen Sie vor dem Einreichen von Protokollen private Schlüssel, Zertifikatspasswörter, Zugriffstoken und Geschäftsdaten. Welche Konto-, Bestell- und Ticketdaten verarbeitet werden, erfahren Sie in der Datenschutzerklärung.

Datenschutzerklärung ansehen

Unsere Prinzipien

Erst Fakten, dann Ihre Entscheidung

Wir vermieten ausschließlich dedizierte physische Macs. Unsere Empfehlungen stützen sich auf technische Daten, Abrechnung und konkrete Schritte – nicht auf ein Versprechen, das nur schneller klingt.

Klare Zahlen

Chip, Unified Memory, SSD, Preise je Laufzeit und verfügbare Standorte sind einzeln aufgeführt. Beispiele sind als solche gekennzeichnet: Ein Vorführzeitpunkt wird nicht als Monitoring-Datum ausgegeben und das Ergebnis eines einzelnen Projekts nicht als Leistungsversprechen für alle Teams dargestellt.

Technische Daten prüfen

Preise ohne Überraschungen

Für Tag, Woche, Monat und Quartal gibt es jeweils einen klar ausgewiesenen Preis. Speichererweiterungen und Thunderbolt 5 im Parallelbetrieb werden separat aufgeführt. Abrechnung ausschließlich in US-Dollar. Als Zahlungsmethoden werden nur USDT-TRC20 und Visa / Mastercard / Amex (über Stripe) unterstützt. Welche Zahlungsanbieter tatsächlich verfügbar sind, zeigt die Antwort der Backend-Schnittstelle.

Optionen einzeln aufgeführt

Dokumentation statt Werbeversprechen

Wir erklären zuerst, wie Sie sich verbinden, die Toolchain fixieren und Runner registrieren, bevor wir über zusätzliche Rechner sprechen. Bringen Sie Ihre erste Pipeline zum Laufen und protokollieren Sie Dauer und Ressourcennutzung. Danach können Sie entscheiden, ob eine stärkere Konfiguration oder zusätzliche parallele Rechner sinnvoll sind.

Erst testen, dann erweitern

Mit einem reproduzierbaren Build starten

Sehen Sie sich die drei Rechnerkonfigurationen und vier Laufzeiten an und testen Sie zunächst mit Ihrem Projekt. Wenn Sie bei der Auswahl unsicher sind, nennen Sie uns Build-Häufigkeit, Toolchain und Parallelitätsbedarf.

Cloud-Mac mieten Alle Angebote ansehen Beratung zur Konfiguration