OSXBuild bietet dedizierte Cloud-Macs für Builds. Sie erhalten eine komplette physische Maschine statt einer virtuellen. Sie behalten die Kontrolle über Code, Toolchain und Signierung – wir stellen die Maschine an einem flexibel mietbaren Standort bereit.
2 Konfigurationen · 6 physische Standorte · ab $20.1/Tag
Wer den Build-Mac selbst betreibt, merkt die Herausforderungen oft nicht beim ersten Archive, sondern beim nächsten Release: Sind Maschine, Cache und Signierungsdaten dann noch genauso verfügbar?
Ein Mac im Büro hängt von den Bedingungen vor Ort ab. Ein Stromausfall oder eine unterbrochene Verbindung kann einen Remote-Job kurz vor dem Archivieren stoppen. Sind Sie unterwegs, muss erst jemand zum Rechner, bevor sich die Build-Logs weiter untersuchen lassen.
Wir holen den Build-Knoten vom Schreibtisch ins Rechenzentrum. Die Maschinen laufen 365 Tage im Jahr; Status und Übergabeinformationen finden Sie im Control Panel.
Debugging, Simulator-Tests und Release-Archive laufen parallel. Wer zuerst startet und wer den Cache löscht, muss im Team abgestimmt werden. Und selbst nach einem erfolgreichen Build bleibt oft die Frage, warum beim nächsten Mal alle Abhängigkeiten erneut geladen werden.
Auf dedizierten Knoten teilen Sie CPU, Arbeitsspeicher und Speicherplatz nicht mit anderen Kunden. Richten Sie Ihre Runner nach dem Bedarf Ihres Teams ein, statt auf fremde Jobs zu warten.
Zertifikate, Profile, Exportoptionen und Skripte verteilen sich auf verschiedene Rechner. Schnell weiß dann nur noch eine Person, wie der Release-Prozess funktioniert. Bei einem Maschinenwechsel muss auch der Workflow neu eingerichtet werden.
Wir empfehlen, Build-Konfigurationen in der Versionsverwaltung abzulegen und Signierungsdaten in einem geschützten Schlüsselbund oder einem geregelten Schlüsselmanagement zu verwahren. Private Schlüssel gehören nicht in gemeinsam genutzte Repositories.
Darum konzentrieren wir uns auf dedizierte Cloud-Macs: Wir ändern weder Ihren Anwendungscode noch machen wir das Signieren zu einer Blackbox. Sie erhalten eine kontrollierbare Maschine, auf der Ihre bestehenden Workflows mit Xcode, Fastlane und CI zuverlässig laufen.
Vor der Bestellung sollten Sie wissen, was Sie mieten, wie die Kosten berechnet werden und wo die Maschine steht.
Sie erhalten einen dedizierten Mac mini, keine virtuelle Maschine auf einem gemeinsam genutzten Host. Sie verwalten Systemumgebung, Build-Cache und Job-Warteschlangen selbst. Build-Jobs anderer Kunden laufen nicht auf Ihrer Maschine.
Dediziert bedeutet nicht unbegrenzte Parallelität. Mehrere Jobs teilen sich weiterhin die Ressourcen derselben Maschine. Messen Sie zunächst die Dauer eines einzelnen Archive-Vorgangs und legen Sie dann die Anzahl paralleler Tests fest.
Beide Konfigurationen sind tage-, wochen-, monats- oder quartalsweise buchbar. Grundausstattung, zusätzlicher SSD-Speicher und Thunderbolt-5-Verbindung zur parallelen Nutzung sind separat ausgewiesen – statt einer vagen „Einstiegskonfiguration“ gibt es eine vollständige Übersicht.
Alle Preise werden in US-Dollar berechnet. Prüfen Sie vor dem Absenden der Bestellung Konfiguration, Standort, Laufzeit, Zusatzoptionen und Gesamtbetrag. Welche Zahlungsarten verfügbar sind, zeigt die Backend-Schnittstelle an.
Standorte sind keine bloßen Punkte auf einer Karte. Beide Konfigurationen sind an allen sechs unten aufgeführten physischen Standorten verfügbar. Den aktuellen Status sehen Sie direkt im Control Panel.
Die geografische Entfernung ist keine Latenzgarantie. Bei der interaktiven Entwicklung zählt die Verbindung zwischen Ihnen und dem Standort. Für automatische Builds spielen außerdem Repository, Paketquellen und Zielsystem für die Artefakte eine Rolle.
Grenzen Sie die Auswahl zunächst anhand der wichtigsten Arbeitsorte Ihres Teams ein und prüfen Sie anschließend die Verbindung in der Praxis. Die Zeitzonen helfen bei der Planung von Zusammenarbeit und Builds, sind aber keine Zusage für Netzwerk-Latenzen.
Für Teams in Südostasien. Interaktive Entwicklung am Tag und automatische nächtliche Archive lassen sich in derselben Umgebung ausführen – ohne auseinanderlaufende lokale und CI-Konfigurationen.
Für Teams in Ostasien. Planen Sie Nightly-Builds passend zu den lokalen Arbeitstagen und übergeben Sie Archive, Exporte und Uploads am nächsten Tag an die Testabläufe.
Für Teams in Nordostasien. Ideal, wenn Entwickler Xcode-, Simulator- und Signierungsprobleme während derselben Arbeitszeit gemeinsam untersuchen müssen.
Für Teams in Südchina und Südostasien. Bei der täglichen Nutzung eines Remote-Desktops sollten Sie Bildqualität, Auflösung und lokale Verbindung prüfen, bevor Sie sich für einen langfristigen Standort entscheiden.
Für Teams an der US-Ostküste und in Westeuropa. Legen Sie Übergaben über mehrere Zeitzonen mit einer klar angegebenen Zeitzone fest, damit die Zeitumstellung Ihre Zeitpläne nicht verschiebt.
Für Teams an der US-Westküste. Remote-Entwicklung und Release-Bereitschaft können sich nach den lokalen Arbeitszeiten richten. Teams über den Pazifik hinweg sollten vorab festlegen, wo Logs und Artefakte übergeben werden.
Die Zeitzonen in den USA wechseln zwischen Standard- und Sommerzeit. Geben Sie für automatische Jobs eine Zeitzone explizit an. Hostname, Port und Zugangsdaten finden Sie in den Informationen zur Bereitstellung im Control Panel. Die Standortbeschreibung ersetzt keinen Verbindungstest.
Teams interessiert nicht, wo die Maschine steht, sondern ob der nächste Build in der vertrauten Umgebung läuft.
„Seit wir OSXBuild nutzen, müssen wir keinen Schreibtisch mehr für unseren Build-Mac freihalten.“
Engineering Manager
„Der Standort Hongkong ist nah. Xcode lässt sich über den Remote-Desktop flüssig bedienen.“
iOS-Entwickler
Wie sich der Remote-Desktop anfühlt, hängt von Ihrem lokalen Netzwerk, der Entfernung zum Standort und den Bildeinstellungen ab. Testen Sie vor dem Umzug die Verbindung, den Download von Abhängigkeiten und ein vollständiges Archive mit Ihrem eigenen Projekt. Entscheiden Sie danach über die Laufzeit.
Wir stellen die Rechenumgebung bereit, nicht Ihre Projektkonfiguration. Quellcode, Abhängigkeitsversionen, Signierungsrechte und Artefakt-Backups muss Ihr Team weiterhin selbst verwalten.
Sie benötigen eine macOS-Oberfläche und die Kommandozeile, um Xcode zu nutzen, Simulatoren auszuführen sowie Apps remote zu archivieren und zu exportieren. Für einfache Builds können Sie mit M4 / 16GB / 256GB starten.
Gleichen Sie bei der Migration zuerst die Xcode-Version und die Lockfiles Ihrer Abhängigkeiten ab. Führen Sie einen sauberen Build aus und stellen Sie den Cache danach schrittweise wieder her. Machen Sie zufällig funktionierende lokale Pfade nicht zur Teamkonfiguration.
Sie benötigen dedizierte Runner, einen persistenten Abhängigkeits-Cache und einen kontrollierbaren Signierungsprozess. Binden Sie vorhandene GitHub Actions, GitLab Runner oder Jenkins ein und übergeben Sie Build-Artefakte nach Ihren bestehenden Regeln.
Legen Sie zuerst die Basiswerte für einen einzelnen Job fest und erfassen Sie Archivierungsdauer, Speicherbedarf und Testressourcen. Erhöhen Sie erst danach die Parallelität. Ein erfolgreicher Build ist noch keine fertige Auslieferung: Export, Upload und Prüfungen durch die Testgruppe gehören ebenfalls in die Pipeline.
Sie möchten MLX oder llama.cpp auf echter Apple-Silicon-Hardware nutzen und Modellladen, Inferenz-Workflows sowie Tool-Kompatibilität prüfen. M4 Pro / 64GB / 2TB ist ein möglicher Einstieg, wenn Sie viel Arbeitsspeicher benötigen.
Ob ein Modell läuft, hängt von der Größe der Gewichte, der Quantisierung, der Kontextlänge und dem Laufzeit-Overhead ab. Testen Sie zuerst Ihr Modell und Ihre Daten und entscheiden Sie dann, ob Sie weitere Maschinen benötigen.
Sichern Sie Quellcode, Skripte, IPA-Dateien, Logs und alle weiterhin benötigten Daten an einem von Ihnen verwalteten Ort. Nach Ende der Laufzeit wird die Maschine zurückgenommen, die Festplatte sicher gelöscht und das System neu installiert. Verlassen Sie sich daher nicht auf den Festplattenspeicher des Knotens als einzige Kopie. Verlängerungen, Bestellungen und Rechnungen finden Sie im Control Panel. Bei Fragen können Sie sich anmelden und ein Support-Ticket einreichen oder eine E-Mail an support@osxbuild.com senden.
Wählen Sie Konfiguration, Laufzeit und Standort und testen Sie ein vollständiges Archive mit Ihrem eigenen Projekt. Bei Fragen zu vielen Builds oder zur Migration können Sie uns Ihre Job-Menge und Toolchain-Version nennen.