Nach Workflow wählen, nicht nach Datenblatt

Ein Cloud-Mac, vier Einsatzbereiche

Ergänzen Sie Ihren Entwicklungsworkflow um einen dedizierten physischen Apple-Silicon-Knoten. Keine virtuelle Maschine: SSH und die grafische macOS-Oberfläche stehen bereit – vom einzelnen Build bis zur dauerhaft laufenden Pipeline und Inferenz auf gemeinsamem Speicher.

Cloud-Mac mieten

Drei Modelle, fünf Standorte. Shell M4 ab $21.8 pro Tag – testen Sie zuerst Ihr eigenes Projekt.

01 / BUILD

Arbeitsrechner behalten,
Xcode in die Cloud verlagern

Sie entwickeln im Alltag unter Windows oder Linux? Synchronisieren Sie zum Veröffentlichen Ihr Repository mit dem Cloud-Mac und starten Sie den Build per SSH. Für Projekteinstellungen, Simulatoren oder Signierung wechseln Sie zur grafischen macOS-Oberfläche – Ihre gesamte Entwicklungsumgebung müssen Sie nicht umziehen.

Mit Shell M4 können Sie zunächst den Build- und Archivierungsablauf eines einzelnen Projekts testen. Ob 16 GB gemeinsamer Speicher ausreichen, hängt von Projektgröße, Zahl der Simulatoren und gleichzeitig laufenden Tools ab. Erfassen Sie zuerst den maximalen Speicherverbrauch und die Dauer eines sauberen Builds, bevor Sie auf ein größeres Modell wechseln.

  • Prüfen Sie die im Projekt festgelegten Xcode- und Abhängigkeitsversionen, damit ein lokal erfolgreicher Build nicht remote fehlschlägt.
  • Führen Sie zunächst einen Build ohne Signierung aus. Richten Sie anschließend Zertifikate und Profile ein, zu deren Verwendung Sie berechtigt sind.
  • Ein erfolgreiches Archiv bedeutet noch keine fertige Veröffentlichung. Prüfen Sie Signierungs- und Vertriebsberechtigungen sowie die erzeugten Artefakte gesondert.
02 / AUTOMATE

Für macOS-Builds:
ein dauerhaft verfügbarer Runner

Registrieren Sie den dedizierten physischen Knoten als selbst gehosteten Runner für GitLab oder GitHub. So laufen Commits, Tests, Archivierung und Artefakt-Upload in derselben Pipeline. Der Knoten läuft ganzjährig 365 Tage; Aufgabenplanung, Prozessüberwachung und Build-Bereinigung konfiguriert Ihr Team passend zum Projekt.

24 GB gemeinsamer Speicher und 512 GB SSD im Shell M4 Plus bietet Reserve für Abhängigkeitsauflösung, Builds und Tests sowie Platz für Repository, Abhängigkeits-Cache und Build-Artefakte. Beginnen Sie mit einer parallelen Aufgabe und erhöhen Sie den Wert erst, nachdem Sie CPU, Speicherdruck und Festplattenwachstum beobachtet haben. Logische Parallelität ist nicht gleich tatsächlicher Durchsatz.

  • Verwenden Sie für CI einen eigenen macOS-Benutzer, statt Arbeitsverzeichnisse mit interaktiven Desktop-Sitzungen zu teilen.
  • Kennzeichnen Sie Runner mit macOS, Chiparchitektur und Xcode-Version, damit Jobs auf dem richtigen Knoten landen.
  • Prüfen Sie bei Aufgaben mit grafischer Sitzung oder Signierungsschlüsselbund zuerst die Berechtigungen in derselben Benutzersitzung.
  • Lassen Sie nur vertrauenswürdige Repositorys auf Runner zugreifen, die Veröffentlichungszugangsdaten enthalten. Externe Beiträge müssen isoliert bleiben.
03 / VERIFY

Nachttests mit nachvollziehbaren Ergebnissen

fastlane organisiert die Aufgaben, XCUITest führt UI-Tests aus und das Ergebnis-Bundle hält den Fehlerkontext fest. Fixieren Sie zuerst die Testumgebung, bevor Sie die Geräteabdeckung erweitern.

Regressionstests zuerst im Simulator

Installieren Sie die vom Projekt benötigte Simulator-Runtime und legen Sie Zielgerät und Betriebssystemversion fest. Prüfen Sie zunächst mit xcrun simctl list devices available die verfügbaren Ziele und tragen Sie dann die tatsächliche Gerätekennung in die Testkonfiguration ein.

Speichern Sie bei nächtlichen Jobs .xcresult, Screenshots und Logs. Unterscheiden Sie bei Fehlern zunächst zwischen Produktfehlern, instabilen Tests und Problemen mit der Umgebung, statt die Ursache mit endlosen Wiederholungen zu verschleiern.

Geeignet für: Commit-Prüfungen und nächtliche Regressionstests

iOS-Tests auf echten Geräten separat klären

Ein gemieteter physischer Mac umfasst nicht automatisch ein iPhone oder iPad. iOS-Geräte sind nicht im Serviceangebot enthalten; ein Gerätezugang ist auch nicht standardmäßig zugesichert. Klären Sie vor der Bestellung, wem die Geräte gehören, wie sie verbunden werden und welche Testtools zum Einsatz kommen.

Ein USB-Gerät an Ihrem Computer erscheint nicht automatisch per SSH auf dem Remote-System. Für den Test benötigen Sie ein erreichbares Gerät, eine eingerichtete Kopplung und Vertrauensstellung sowie die nötigen Signierungsrechte. Klären Sie die Machbarkeit vorab per E-Mail.

Bedingungen für Gerätetests per E-Mail klären

Für jeden Lauf ein Ergebnis-Bundle speichern

Führen Sie den Befehl aus, nachdem die fastlane-Test-Lane im Projekt eingerichtet wurde. Sortieren Sie Ergebnisverzeichnisse nach Job-ID und übertragen Sie sie nach dem Test, statt sie dauerhaft auf dem Knoten zu sammeln.

bundle exec fastlane scan \
  --scheme App \
  --result_bundle true \
  --output_directory build/test-results
04 / EXPERIMENT

Gemeinsamen Speicher nutzen,
Inferenzannahmen überprüfen

Shell M4 Pro kombiniert einen M4 Pro Chip, 64 GB gemeinsamen Speicher und eine 2-TB-SSD. Damit lassen sich mit MLX oder llama.cpp Modell-Loading, Quantisierungsvarianten, Kontextlängen und Metal-Inferenz testen. CPU und GPU greifen auf denselben Speicher zu – das bedeutet jedoch nicht, dass der gesamte Speicher für Modellgewichte verfügbar ist.

Kalkulieren Sie bei der Modellauswahl zuerst den Speicherbedarf der Gewichte und planen Sie dann Betriebsreserve ein. Bei 4-Bit-Gewichten benötigen 8B-Modelle grob 4 GB und 32B-Modelle etwa 16 GB. Das ist lediglich eine Schätzung aus Parameterzahl × 0,5 Byte und berücksichtigt weder Quantisierungsmetadaten noch KV-Cache, Laufzeit oder Systemverbrauch. Daraus lässt sich nicht ableiten, dass ein bestimmtes Modell sicher geladen werden kann.

  • Messen Sie zuerst mit kurzem Kontext und einer einzelnen Anfrage die Latenz bis zum ersten Token und die stabile Generierungsgeschwindigkeit. Erhöhen Sie erst danach Kontextlänge oder Parallelität.
  • Halten Sie Modellversion, Quantisierungsformat, Tool-Version und Sampling-Parameter fest, damit Ergebnisse unterschiedlicher Konfigurationen nicht miteinander verwechselt werden.
  • Für Aufgaben, die das CUDA-Ökosystem oder Multi-GPU-Training erfordern, ist dieser Mac kein direkter Ersatz.
Vom lokalen Rechner in die Cloud

Migration in drei Schritten, jeder einzeln überprüfbar

Kopieren Sie nicht einfach Ihr gesamtes Benutzerverzeichnis. Migrieren Sie zuerst das Projekt, stellen Sie dann die Toolchain wieder her und verlagern Sie zuletzt die Jobs. Die Zeitangaben sind Schätzwerte für die manuelle Planung, keine Zusage für die Bereitstellung. Download, Übertragung und Build kommen hinzu.

01

Daten: Repository wiederherstellbar machen

Zeitaufwand: 10–30 Minuten, ohne Übertragung

Klonen Sie bei der ersten Migration vorzugsweise das Repository; synchronisieren Sie nicht committete Ressourcen separat inkrementell. Führen Sie den folgenden Befehl lokal aus:cloud-mac ist Ihr bereits konfigurierter SSH-Alias. Die Repository-Adresse stammt aus einer Umgebungsvariablen Ihres Projekts.

ssh cloud-mac 'mkdir -p ~/work'
rsync -av --exclude '.git' \
  ./App/ cloud-mac:~/work/App/
ssh cloud-mac
git clone "$REPOSITORY_URL" ~/work/repo

Abnahme: Commit-Hash stimmt überein und erforderliche Ressourcen sind vorhanden. Caches und wiederherstellbare Build-Verzeichnisse müssen nicht migriert werden.

02

Toolchain: Versionen und Berechtigungen festlegen

Zeitaufwand: 20–60 Minuten, ohne Download

Prüfen Sie remote den Xcode-Pfad und die SDKs. Stellen Sie Tools mit Homebrew wieder her, wenn ein Brewfile vorhanden ist. Übertragen Sie Zertifikate und Profile über einen vom Team genehmigten sicheren Weg – niemals ins Repository oder in Job-Logs.

xcode-select -p
xcodebuild -version
xcodebuild -showsdks
brew bundle --file Brewfile
security list-keychains -d user

Abnahme: Abhängigkeitsversionen stimmen überein und das Ziel-SDK ist verfügbar. Erstellen Sie unter dem tatsächlich ausführenden Benutzer ein signiertes Archiv.

03

CI: erst testen, dann Labels umstellen

Zeitaufwand: 15–45 Minuten, ohne Build

Binden Sie den Runner mit den von Ihrer Organisation bereitgestellten Registrierungsdaten ein. Die folgenden Befehle gelten für GitLab; für GitHub Runner verwenden Sie das von Ihrer Organisation bereitgestellte Setup-Skript und prüfen den Dienststatus auf dem Knoten. Geben Sie das Token nur in einer vertrauenswürdigen Sitzung ein.

gitlab-runner register
gitlab-runner install
gitlab-runner start
gitlab-runner verify

Abnahme: Ein Test-Branch wird dem neuen Label zugewiesen und die Artefakte lassen sich herunterladen. Wechseln Sie erst nach erfolgreicher Prüfung zur regulären Pipeline und behalten Sie den bisherigen Runner für einen möglichen Rollback.

Migrationserfolg bedeutet nicht nur, dass eine SSH-Verbindung möglich ist. Derselbe Commit muss Abhängigkeitsinstallation, Build, Tests und Artefakt-Upload durchlaufen. Schlägt ein Schritt fehl, sichern Sie zuerst die Logs und fahren Sie erst dann fort.

Übergabe über Zeitzonen hinweg

Gemeinsam geplant, keine gemeinsam genutzten Passwörter

Ein Team kann denselben Knoten zeitversetzt nutzen, doch CPU, GPU, Speicher und Festplatte bleiben gemeinsam genutzte Ressourcen. Mehrere Systembenutzer bilden keine Isolationsgrenze wie virtuelle Maschinen. Veröffentlichungszugangsdaten und sensible Projekte erfordern ein sorgfältigeres Berechtigungskonzept.

  1. 01

    Eigene Konten für alle

    Jedes Teammitglied verwendet einen eigenen macOS-Benutzer und SSH-Schlüssel, statt private Schlüssel zu teilen. CI erhält ein separates Konto. Verlässt jemand das Team, entfernen Sie den Schlüssel und prüfen Sie zugehörige Tokens.

  2. 02

    Aufgaben sauber übergeben

    Planen Sie in einer gemeinsamen Zeitzone. Halten Sie bei der Übergabe Commit-Hash, Arbeitsverzeichnis, laufende Prozesse und nächste Aufgabe fest. Übergeben Sie lange Jobs an den Runner oder eine verwaltete Sitzung, statt eine Desktop-Verbindung dauerhaft offen zu lassen.

  3. 03

    Signierung getrennt verwalten

    Prüfen Sie die Schlüsselbundberechtigungen für den ausführenden Benutzer und speichern Sie Entsperrpasswörter nicht im Shell-Verlauf. Stellen Sie vor der Übergabe sicher, dass keine interaktive Signierungsabfrage offen ist. Beenden Sie nicht mitten in einem Veröffentlichungsjob die Benutzersitzung einer anderen Person.

  4. 04

    Daten doppelt sichern

    Übertragen Sie Code zurück ins Repository und Build-Artefakte in den Teamspeicher. Zugangsdaten werden separat sicher verwahrt. Erstellen Sie vor Ablauf ein Backup und nutzen Sie den Knoten nicht als einzigen Speicherort. Maßgeblich für Verlängerung und Ablauf sind die Angaben in der Konsole.

NÄCHSTER SCHRITT / PROJEKT STARTEN

Wählen Sie zuerst die Aufgabe,
und starten Sie dann Ihren ersten Knoten

Für Builds einzelner Projekte eignet sich Shell M4, für Team-Pipelines Shell M4 Plus und für Inferenzexperimente mit hohem Speicherbedarf Shell M4 Pro. Bestätigen Sie auf der Bestellseite Laufzeit, Standort und Zusatzoptionen.

Zahlung nur mit USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe); abgerechnet wird in USD. Welche Zahlungswege tatsächlich verfügbar sind, hängt von der Rückmeldung des Backend-Gateways ab.

Einzelentwicklung · Shell M4 Team-CI · Shell M4 Plus KI-Experimente · Shell M4 Pro