Einsatzbereiche

Ein Remote-Mac, drei Einsatzmöglichkeiten

Nutzen Sie einen dedizierten physischen Mac für die Xcode-Entwicklung, automatisierte Builds oder Modellinferenz. Greifen Sie per Bildschirmfreigabe oder VNC auf den grafischen Desktop zu und verbinden Sie sich bei Bedarf per SSH. Die Rechenleistung wird nicht mit anderen Kunden geteilt.

Remote-Mac mieten Modelle & Preise

Zwei M4-Konfigurationen, mietbar pro Tag, Woche, Monat oder Quartal. Die aktuelle Verfügbarkeit der einzelnen Knoten sehen Sie direkt in der Konsole.

Ein Rechner, flexibel eingesetztDedizierter physischer Knoten · Desktop + SSH

Xcode-ArbeitsbereichEntwickeln · Simulator · Testbuild verteilen

Desktop

Automatisierte Build-PipelineSelbst gehosteter Runner · Signierung · Archivierung

Lokale InferenzsitzungMLX / llama.cpp · Ausgaben überwachen

Inferenz

Planen Sie Zeitfenster und Konten passend zum jeweiligen Einsatz. Die gleichzeitige Nutzung desselben Desktops ist keine geeignete Form der Zusammenarbeit.

App-EntwicklungXcode & Simulator Continuous IntegrationBuilds & Signierung ModellinferenzUnified Memory & Gewichte

Für iOS- und macOS-Entwickler

Xcode läuft remote – Sie behalten die Kontrolle über den Entwicklungsablauf

Öffnen Sie den grafischen macOS-Desktop per Bildschirmfreigabe oder VNC, bearbeiten Sie Projekte remote, starten Sie Xcode und prüfen Sie Build-Logs. Simulatoren und Kompilierungen nutzen CPU, GPU und Unified Memory dieses physischen Rechners und belasten nicht den Computer vor Ihnen.

Wenn Sie eine Version an Tester ausliefern möchten, können Sie das Archiv erstellen, signieren und über TestFlight verteilen – alles remote. Verwalten Sie Projekt-Repository, Signiermaterial und Exportkonfiguration getrennt. Prüfen Sie vor der ersten Verteilung Zertifikate, Provisioning-Profile und Build-Einstellungen mit einem internen Testbuild.

Grenzen beim Debuggen auf echten Geräten

Ein Cloud-Mac lässt sich nicht direkt mit dem iPhone vor Ort verbinden. Simulator, Kompilierung und Verteilung laufen remote. Für USB-Verbindungen, Geräteprotokolle oder Tests mit direkter Interaktion benötigen Sie zusätzlich ein lokales Gerät und eine lokale Entwicklungsumgebung.

Ein Entwicklungsdurchlauf

01
Desktop verbinden
Wählen Sie einen nahe gelegenen Knoten, prüfen Sie die Bildschirmauflösung und öffnen Sie den Projektarbeitsbereich.
02
Build erstellen & prüfen
Starten Sie zunächst den gewünschten Simulator und prüfen Sie anschließend Speicherbelegung und Build-Ausgabe.
03
Testbuild ausliefern
Prüfen Sie die Signierungseinstellungen, erstellen Sie das Archiv und verteilen Sie es über TestFlight.

Für CI/CD-Teams

Ein fester Mac für automatisierte Builds

Registrieren Sie den physischen Knoten als selbst gehosteten Runner, damit Codeabruf, Installation von Abhängigkeiten, Tests, Archivierung und Export mit derselben Toolchain ablaufen. Der grafische Desktop eignet sich für erste Freigaben, die Prüfung der Signierung und die Fehlersuche. Im Alltag übernimmt der Runner die Pipeline im Hintergrund.

Begrenzen Sie vor nächtlichen Batch-Builds die Zahl paralleler Jobs, damit Simulatoren und Archivierungsaufgaben nicht gleichzeitig den Unified Memory auslasten. Speichern Sie Signierschlüssel in einem kontrollierten Secret Store und legen Sie sie nicht im Repository ab. Entfernen Sie nach dem Build temporäre Dateien und hinterlassen Sie für die nächste Person Fehlerprotokolle und Änderungsnotizen.

Ersetzen Sie beim ersten Durchlauf nicht gleich die Produktionspipeline. Prüfen Sie zunächst eine App, ein Build-Ziel und einen Signierexport, bevor Sie schrittweise weitere Aufgaben migrieren.

Runner-Setup prüfen

Xcode-Version und Pfad der Command-Line-Tools festlegen
Ruby, CocoaPods und Projekt-Lockdateien aufeinander abstimmen
Signierzugang auf die erforderlichen Build-Jobs beschränken
Logs, Laufzeit und Prüfergebnisse des ersten Durchlaufs festhalten

Für Teams mit Modell-Experimenten

Inferenz auf Apple Silicon nachvollziehbar testen

Legen Sie quantisierte Modellgewichte auf dem Remote-Speicher ab und starten Sie Inferenztests mit kleinen bis mittelgroßen Modellen über MLX oder llama.cpp. Führen Sie Skripte per SSH aus und prüfen Sie Terminalausgaben, Aktivitätsanzeige und Ergebnisdateien auf dem Remote-Desktop. Für Präsentationen können Sie auch die grafische Sitzung freigeben.

Schätzen Sie den Speicherbedarf anhand der Gewichtsgröße, der Kontextlänge und der Parallelität ein – nicht allein anhand des Modellnamens. XV Studio M4 bietet einen M4, 24 GB Unified Memory und eine 512-GB-SSD. Wenn Ihre Tests mehrere Gewichtssätze oder größere Datensätze umfassen, können Sie bei der Bestellung die zusätzliche 1-TB-SSD wählen. Mehr Speicherplatz bedeutet nicht mehr Unified Memory.

Prüfen Sie mit einer kleinen Stichprobe zunächst das Laden, die Zeit bis zur ersten Ausgabe und den Ressourcenverbrauch bei laufender Inferenz. Entscheiden Sie erst danach, ob Sie die Mietdauer verlängern. Ob ein Modell vollständig in den Speicher passt, hängt weiterhin vom konkreten Quantisierungsformat und den Laufzeitparametern ab.

Vor dem Test vier Werte notieren

Gewichte: Quantisierungsformat und Dateigröße
Kontext: Ziel-Länge und Batch-Größe
Speicherbelegung: Verfügbarer Unified Memory nach dem Laden
Ergebnisse: Ausgabepfad und reproduzierbare Testparameter

Übergabe über Zeitzonen hinweg

Ein Entwicklungsrechner, nacheinander genutzt

Lassen Sie Teammitglieder in verschiedenen Zeitzonen nach festen Zeitfenstern denselben physischen Mac nutzen. Die vorherige Person committet den Code, meldet sich vom Desktop ab und notiert den aktuellen Branch sowie laufende Builds. Die nächste Person liest zuerst die Übergabenotiz und startet dann ihre Sitzung. So teilen Sie die Nutzungszeit des Geräts, nicht dauerhaft ein persönliches Login.

Diese Angaben gehören in die Übergabenotiz

Aktueller Branch, letzter erfolgreicher Build und Speicherort der Artefakte
Laufende Aufgaben, offene Fehler und nächste Schritte
Zeitpunkt der nächsten Verbindung und Zuständigkeit für länger laufende Jobs

Richten Sie für jedes Teammitglied ein eigenes Systemkonto ein und vergeben Sie Berechtigungen nach Aufgabenbereich. Übermitteln Sie Zugangsdaten über einen kontrollierten Kanal und nicht in gemeinsam genutzten Notizen. Vermeiden Sie, dass zwei Personen gleichzeitig denselben grafischen Desktop steuern.

Migrationsablauf

Erst das Projekt migrieren, dann die Tools abstimmen, zuletzt die Pipeline anbinden

Beginnen Sie mit einer kleinen, rückgängig zu machenden Migration. Ändern Sie am ersten Tag nicht gleichzeitig Betriebssystem, Xcode, Abhängigkeitsverwaltung und Build-Einstieg.

01 / Daten

Projekt und Zertifikate getrennt migrieren

Committen und prüfen Sie zuerst das Code-Repository. Übertragen Sie nicht versionierte Projektdaten anschließend mit rsync oder als verschlüsseltes Archiv. Übertragen Sie Signierzertifikate und Konfigurationsdateien separat und beschränken Sie den Lesezugriff. Private Schlüssel gehören nicht in gewöhnliche Projektarchive.

Abnahme:Das Repository lässt sich auschecken, alle benötigten Dateien sind vorhanden und sensible Daten tauchen nicht in der Commit-Historie auf.

02 / Toolchain

Reproduzierbare Versionen festhalten

Notieren Sie die im Projekt verwendete Xcode-Version und prüfen Sie Command-Line-Tools, Homebrew-Abhängigkeiten, Ruby und CocoaPods. Installieren Sie die Abhängigkeiten zunächst remote und führen Sie einen Build lokal auf dem Rechner aus. Beheben Sie Versionsabweichungen einzeln.

Abnahme:Derselbe Commit wird remote kompiliert und besteht die Tests im vorgesehenen Simulator.

03 / CI-Anbindung

Eine Pipeline testweise ausführen

Registrieren Sie einen selbst gehosteten Runner und richten Sie Repository-Zugriff sowie Signierschlüssel mit den geringstmöglichen Berechtigungen ein. Starten Sie zunächst einen Testbuild, anschließend Archivierung und Export. Halten Sie Laufzeit, Fehlerprotokolle und Speicherort der Artefakte fest.

Abnahme:Der erste Ablauf lässt sich wiederholen, ohne vorübergehende manuelle Schritte ergänzen zu müssen.

Konfiguration nach Arbeitslast wählen

Erst die parallelen Aufgaben prüfen, dann Speicher und Kapazität wählen

Beide Konfigurationen bieten einen dedizierten physischen Rechner mit Bildschirmfreigabe, VNC und SSH. Die folgenden Empfehlungen sind ein Ausgangspunkt – entscheidend sind Ihr Projekt und der tatsächliche Modellbedarf.

Empfehlungen für Arbeitslasten und die beiden M4-Konfigurationen
Arbeitslast	Empfohlene Konfiguration	Auswahlkriterien & Prüfpunkte
Leichte Builds und Remote-Präsentationen	XV Desk M4 M4 · 16 GB · 256 GB	Geeignet für die Bearbeitung einzelner Projekte, übliche Kompilierungen und Präsentationen. Prüfen Sie, ob Projekt, Abhängigkeiten und Build-Artefakte auf den verfügbaren Speicherplatz passen.
Tägliche Entwicklung und Simulatoren	XV Desk M4 oder XV Studio M4	Für ein einzelnes Ziel können Sie mit dem Desk starten. Bei mehreren parallelen Simulatoren, häufigen Archivierungen oder größeren Projekten sollten Sie den Studio mit 24 GB Unified Memory in Betracht ziehen.
Inferenz quantisierter Modelle	XV Studio M4 M4 · 24 GB · 512 GB Optional: 1-TB-SSD	Prüfen Sie zuerst den Speicherbedarf von Gewichten und Kontext. Wenn mehrere Gewichtssätze zusätzlichen Platz benötigen, wählen Sie die Speichererweiterung.

Vollständige Spezifikationen & Laufzeitpreise

Kreatives Arbeiten & Präsentationen

Auch kurze Clips lassen sich remote schneiden – beachten Sie aber die Grenzen der Bildübertragung

Für kurzfristig benötigtes Präsentationsmaterial können Sie Clips mit Final Cut Pro remote sortieren, eine grobe Schnittfassung erstellen und eine Vorschau exportieren. Für die Präsentation einer macOS-App geben Sie einfach den Remote-Desktop frei, damit Kunden den Ablauf und die tatsächliche Benutzeroberfläche sehen.

Bildrate, Bildqualität und Reaktionsgeschwindigkeit des Remote-Desktops hängen von den Client-Einstellungen und dem Netzwerkpfad ab. Für Rohschnitte, Ablaufpräsentationen und Ergebnisprüfungen ist er gut geeignet. Für Bild-für-Bild-Entscheidungen, Echtzeit-Farbkorrektur und eine präzise Prüfung der Audio-Bild-Synchronität sollten Sie eine lokale Anzeige- und Wiedergabeumgebung verwenden.

Nächster Schritt

Arbeitslast in die Tarifauswahl übernehmen und passend buchen

Für leichte Builds bietet sich der XV Desk M4 an. Bei mehreren Simulatoren oder Modellinferenz sollten Sie zuerst den XV Studio M4 prüfen. Wählen Sie Knoten, Laufzeit und Speichererweiterung nach Ihrem tatsächlichen Bedarf.

Remote-Mac mieten Beide Mietoptionen ansehen