Einmal testen
Ein Test-Build erstellen oder prüfen, ob sich das Projekt mit der vorgesehenen Toolchain bauen lässt.
M4 Pro $59/Tag
Mac-Entwicklungsrechner · für Flutter-, React-Native- und Unity-Entwickler
Entwickeln Sie weiter auf Ihrem gewohnten Rechner und verlagern Sie nur die macOS-abhängigen Build-Schritte in die Cloud.
Passend zum Projekt planen
Mieten Sie so lange, wie Ihr Projekt es erfordert. Wählen Sie beim Buchen aus vier Laufzeiten.
Ein Test-Build erstellen oder prüfen, ob sich das Projekt mit der vorgesehenen Toolchain bauen lässt.
Richten Sie Integration und Tests für Ihr Projekt ein und erledigen Sie Signaturprüfungen sowie Korrekturen in derselben Umgebung.
Behalten Sie Abhängigkeiten und Build-Verzeichnisse während der Entwicklung bei und sparen Sie sich wiederholte Einrichtung der Build-Umgebung.
Richten Sie einen self-hosted runner für Continuous Delivery ein und integrieren Sie die Build-Umgebung in Ihre Teamabläufe.
Nach Ablauf ohne Verlängerung endet der Dienst – ohne langfristigen Vertrag.
Schätzen Sie zunächst den Zeitbedarf für Kompilierung, Tests auf echten Geräten und Korrekturen. Wählen Sie dann die passende Laufzeit. Ein einmaliger Build-Test und regelmäßige Builds für ein Team sind unterschiedliche Anwendungsfälle. Planen Sie die Mietdauer nicht allein anhand der ersten Archive-Dauer.
Umgebung verbinden
Von der Konfigurationswahl bis zum Build: Folgen Sie diesen drei Schritten.
Wählen Sie Modell, Standort und Abrechnungszeitraum. Prüfen Sie den Betrag und schließen Sie die Zahlung ab.
Der tatsächliche Verfügbarkeitsstatus wird im Kundenportal angezeigt. Halten Sie vorab eine Liste der Projektabhängigkeiten bereit, damit Sie nach dem Verbinden nicht erst nach Build-Dateien suchen müssen.
Rufen Sie nach der Freischaltung Adresse, Port und Zugangsdaten ab und prüfen Sie, zu welcher Bestellung sie gehören.
Speichern Sie die Bestelldaten im Kundenportal. Bei Verbindungsproblemen eröffnen Sie ein Ticket zur betreffenden Bestellung. Veröffentlichen Sie niemals Passwörter, private Schlüssel oder Signaturmaterial in öffentlichen Logs.
Desktop per VNC ansehen, Befehle wiederholt per SSH ausführen und xcodebuildAbhängigkeiten gemäß den Projektanforderungen einrichten.
Prüfen Sie zuerst die Versionen von macOS, Xcode und den Kommandozeilenwerkzeugen und stellen Sie anschließend die Projektabhängigkeiten wieder her. Übertragen Sie nach dem Build die Artefakte und erforderlichen Logs in Ihren eigenen Speicher.
Hardware prüfen
Bei großen Unity-Asset-Paketen oder mehreren parallel laufenden Simulatoren sollten Sie das Modell M4 Pro in Betracht ziehen.
Einstiegsmodell XcodeHost M4: M4 / 16 GB / 256 GB SSD
Der Arbeitsspeicher muss Build-Prozesse, Editor und Simulatoren aufnehmen. Auf dem Speicherplatz müssen außerdem Abhängigkeits-Caches, Build-Verzeichnisse und exportierte Artefakte Platz finden. Prüfen Sie vor der Auswahl den tatsächlichen Speicherbedarf Ihres Projekts. Das Chipmodell allein garantiert keine bestimmte Build-Dauer.
Ausgehend von Ihrem Framework
Sie müssen nicht Ihren gesamten Entwicklungsablauf verlagern. Verbinden Sie zunächst nur den Teil, der einen Mac benötigt.
Schreiben Sie Ihre Anwendungslogik unter Windows, prüfen Sie auf dem Mac die Toolchain, stellen Sie die Abhängigkeiten wieder her und führen Sie anschließend flutter build ipa aus.
Führen Sie zuerst eine Projektdiagnose durch und unterscheiden Sie Probleme mit SDK, nativen Plugins und Signaturkonfiguration. Nach einem erfolgreichen Build müssen Installation und Ausführung geprüft werden – der Exit-Code allein reicht nicht.
Führen Sie in einer Remote-macOS-Umgebung pod install, die Kompilierung nativer Abhängigkeiten, das Archive und den Export aus.
Behalten Sie die Lockdatei des Projekts bei und prüfen Sie die Versionen von Node, Ruby und CocoaPods. Bei Fehlern mit Hermes oder nativen Modulen hilft zunächst ein Blick in das passende Build-Log.
Exportieren Sie unter Windows ein Xcode-Projekt, laden Sie es hoch und kompilieren Sie es auf dem Mac. Prüfen Sie die Signierung und exportieren Sie ein Test-Build.
Prüfen Sie das iOS-Build-Modul von Unity, die Exporteinstellungen und die Plugin-Abhängigkeiten. Ermitteln Sie bei großen Projekten zunächst den Speicherbedarf für Projekt und Zwischendateien und wählen Sie danach die Konfiguration.
Preise in US-Dollar prüfen
Zwei Modelle, vier Laufzeiten. Prüfen Sie zuerst die Ausstattung und wählen Sie dann die passende Mietdauer.
M4 · 16 GB Unified Memory · 256 GB SSD
Für reguläre Builds, die Prüfung nativer Abhängigkeiten und kurze Tests. Prüfen Sie vor dem Start, ob Projekt, Cache und Exportdateien auf den gewählten Speicher passen.
| Pro Tag | $19.9/Tag |
|---|---|
| Pro Woche | $53.8/Woche |
| Pro Monat | $99.7/Monat |
| Pro Quartal | $271.2/Quartal |
M4 Pro · 64 GB Unified Memory · 2 TB SSD
Für Projekte mit höherem Speicher- und Arbeitsspeicherbedarf. Große Unity-Assets, mehrere Simulatoren oder umfangreiche Build-Caches sprechen dafür, dieses Modell in Betracht zu ziehen.
| Pro Tag | $59/Tag |
|---|---|
| Pro Woche | $159.4/Woche |
| Pro Monat | $295.1/Monat |
| Pro Quartal | $802.7/Quartal |
Die Preise gelten für die angegebenen Modelle und Laufzeiten. Zusätzlicher Speicher und Thunderbolt-5-Verbundbetrieb werden auf der Lösungsseite beschrieben. Prüfen Sie bei der Buchung Konfiguration, Gesamtbetrag und Ablaufdatum. Sichern Sie Ihr Projekt zusätzlich zur Build-Umgebung an einem weiteren Ort.
Zugriffsstandort festlegen
Berücksichtigen Sie zuerst den Standort der Hauptnutzer und danach die Wege für Projekt-Uploads und Downloads der Build-Artefakte.
Insgesamt 5 Standorte. Klicken Sie, um zur Buchungsseite zu gelangen und den Standort vorauszuwählen. Der aktuelle Verfügbarkeitsstatus wird im Kundenportal angezeigt.
Jeder Rechner ist eine exklusive physische Maschine, keine virtuelle Maschine. CPU und Arbeitsspeicher werden nicht mit anderen geteilt.
Die grafische macOS-Oberfläche und die Kommandozeile stehen vollständig zur Verfügung. Exklusive Nutzung ersetzt keine Zugriffskontrolle: Schützen Sie Ihre Zugangsdaten und richten Sie den Zugriff entsprechend den Projektanforderungen ein.
Die Standorte sind 365 Tage im Jahr in Betrieb. Die Verfügbarkeitszusage beträgt 99.9%.
Bei einer Berechnung auf Basis von 30 Tagen entspricht das etwa 43 Minuten Ausfallzeit. Wird dieser Wert überschritten, wird die Servicezeit anteilig entsprechend der betroffenen Dauer gutgeschrieben. Reichen Sie Ihren Antrag per Ticket mit Bestellnummer und betroffenem Zeitraum ein.
Es werden ausschließlich die beiden oben genannten Zahlungsmethoden unterstützt. Welche Zahlungswege verfügbar sind, richtet sich nach der Rückmeldung der Backend-Schnittstelle. Bewahren Sie bei Zahlungsproblemen Bestellnummer und Transaktionsbeleg auf und senden Sie niemals die vollständige Kartennummer.
Klarheit vor dem Build
Den Anwendungscode können Sie weiterhin unter Windows oder Linux schreiben. Xcode-Kompilierung, Archive und Export des iOS-Projekts erfolgen auf dem Cloud-Mac. Toolchain, Abhängigkeiten und Signaturmaterial müssen weiterhin für das jeweilige Projekt eingerichtet werden.
Halten Sie je nach Verteilung gültiges Zertifikat, privaten Schlüssel und Provisioning Profile bereit. Prüfen Sie Bundle ID und Zielgeräte. Laden Sie nur die für das aktuelle Projekt erforderlichen Dateien hoch, exportieren Sie nach der Nutzung eine Sicherung und entfernen Sie die Dateien anschließend.
Nein. Sie können nur das für den Build benötigte Projekt samt Ressourcen synchronisieren. Nehmen Sie die Lockdatei der Abhängigkeiten mit, damit keine anderen Versionen wiederhergestellt werden. Lokale Caches und große, nicht benötigte Dateien müssen nicht mitübertragen werden.
Für die grafische Oberfläche verwenden Sie VNC, für wiederholt ausgeführte Befehle SSH. Die Desktop-Interaktion hängt von Ihrer Netzwerkverbindung ab. Kontinuierliche Builds sind über die Kommandozeile möglich. Was Sie für die Verbindung benötigen, erfahren Sie in der Anleitung.
Sie können auf dem Standort einen self-hosted runner einrichten. Testen Sie zunächst einen manuellen Build und richten Sie anschließend automatische Auslöser ein. Build-Zugangsdaten, Repository-Berechtigungen und Aufbewahrungsregeln für Artefakte verwaltet Ihr Projektteam.
Nach Ablauf wird der Rechner abgeschaltet. Daten werden gemäß den Nutzungsbedingungen gelöscht. Sichern Sie Projekt, Zertifikate, Build-Artefakte und erforderliche Logs vor dem Ablauf. Verlassen Sie sich nach der Abschaltung nicht darauf, dass der Rechner weiterhin als Speicher verfügbar ist.
Berücksichtigen Sie Projektgröße, maximalen Speicherbedarf und gleichzeitig ausgeführte Werkzeuge. Für reguläre Tests kommt der M4 infrage, für umfangreiche Ressourcen und parallele Aufgaben der M4 Pro. Die tatsächliche Build-Dauer hängt von Projekt, Abhängigkeiten und Build-Einstellungen ab.
Melden Sie sich im Kundenportal an und eröffnen Sie ein Ticket. Geben Sie Bestellnummer, Zeitpunkt des Problems, Toolversionen und bereinigte Fehler-Logs an. Für Fragen zur Modellauswahl vor dem Kauf oder per E-Mail schreiben Sie an support@xcodehost.com.
Wichtige Schritte festhalten
Lesen Sie die Anleitungen anhand Ihrer konkreten Projektprobleme. Prüfen Sie zunächst die Toolversionen und gleichen Sie dann die einzelnen Schritte ab.
Ein Swift-Prüfskript fixiert die signierten Bytes und erkennt Manipulationen. Dazu kommen klare Regeln für Zeitfenster und die Nonce-Prüfung auf dem Server.
SecurityEin ausführbares Swift-Skript prüft Referenzvektoren, führende Nullen und Zeitgrenzen. Der Wiederholungsschutz bleibt Aufgabe des Servers.
SecuritySwift und CommonCrypto liefern reproduzierbare Referenztests. Dazu kommen Prüfungen für Passwortbytes, Salt und die schrittweise Aktualisierung alter Parameter.
Neue Beiträge in Vorbereitung. Sehen Sie sich zunächst die Blogübersicht an.
Starten Sie mit dem XcodeHost M4 ab $19.9/Tag, wählen Sie die Laufzeit und prüfen Sie anschließend das Ablaufdatum.