Mein Alltagsrechner ist ein leichtes Notebook – Swift, Storyboards, Slack, alles gut. Sobald ich Run drücke oder ein fetter PR einen Full Build auslöst, kenne ich das Programm: Lüfter voll, warmes Trackpad, swift-frontend frisst die CPU, Autocomplete ruckelt. Derived Data löschen, Xcode neu starten, auf Indexing hoffen – kennst du. Der Knackpunkt: Dieses Gerät muss nicht alles Schweres schleppen – xcodebuild, lange Indizes und Archives gehören auf einen dauerhaft eingesteckten Mac.
Heute: dünnes Notebook lokal + dedizierter M4 Mac mini in der Cloud. Notebook für Code und Meetings; Rack-Mac für Kompilieren, Simulator, Signierung. Windows-Teams: Xcode unter Windows. MacBook Pro? TCO Kauf vs Miete; CI: eigene macOS-Runner. Unten mein echter Workflow – kein Einkaufsfolien-Deck.
1) Xcode hängt, weil die Maschine zu viel frisst
SourceKit über das ganze Repo, Indexing auf der Platte, Linker im Clean Build, Simulator im RAM – alles zusammen. Ultrabooks drosseln nach wenigen Minuten Build. Apples Build-Effizienz half mir von 8 auf 5 Minuten – bei mehreren Cleans pro Tag reicht das nicht.
Auf Reisen will ich kein Notebook, das im Hotel-WLAN archiviert. Seit Builds auf einem M4 Mac mini im Rechenzentrum laufen, fühlt sich das Notebook wieder wie ein Terminal an.
2) Aufteilen: hier schreiben, dort bauen
- Lokal: Git, Cursor/VS Code, Design. Build per SSH – Lüfter ruhig.
- Cloud M4 Mac mini: volles Xcode, fester Derived-Data-Pfad,
xcodebuild archive. Dediziert – kein geteilter Mac, den Kollegen vollschreiben. - CI (optional): self-hosted Runner, push, Kaffee, PR grün oder rot.
Region nach Git, nicht nach meinem Heim-ISP. Geteilte macOS-VMs – Signierung und Durchsatz mies; siehe VM vs Bare-Metal Mac mini.
3) Drei Varianten – ich starte mit B
| Modus | Lokal | Cloud M4 | Für wen |
|---|---|---|---|
| A Komplett remote | nur SSH/VNC | GUI, Sim, Builds | Non-Mac-Notebook |
| B Hybrid (Standard) | Edit, push | xcodebuild | Lokale Completion, kein Lüfter |
| C nur CI | täglich Xcode lokal | Runner 24/7 | viele PRs |
Solo: B – tags SwiftUI, abends push, Cloud-Archive nach TestFlight. Cursor? Remote-SSH auf den Cloud-Host.
4) Cloud-Mac dazu?
| Signal | Notebook tunen | Cloud M4 |
|---|---|---|
| Clean >5 Min., mehrmals täglich | begrenzt | Builds umziehen |
| Lüfter stört Calls | Pflaster | kompilieren extern |
| neues Xcode, altes macOS | neues Gerät | Cloud-Image updaten |
| Sim-UI 2+ h/Tag | lokaler Mac hilft | VNC oder Rollen |
| Offline Flug | lokal bauen | Cloud ersetzt nicht |
Im Zweifel Archive auf dem echten Repo stoppen – ehrlicher als jeder Blog-Benchmark.
5) Setup-Reihenfolge
- Region nahe GitHub/GitLab und Artefakten.
- Xcode per SSH, passende Version; Release Notes.
export DERIVED_DATA_PATH=~/DerivedDatain~/.zshrc.git pull, Fastlane Match, VNC bei Gerätevertrauen.ssh build@cloud-mac 'cd ~/app && xcodebuild -scheme App -destination generic/platform=iOS build'
„Gigabit zuhause“ ist egal – SSH stabil, IPA-Upload ruhig. Erster Full Build wärmt Derived Data.
6) Fallen, die ich kannte
Zwei Derived-Data-Welten verwirren Xcode. UI-Feintuning → Sim in der Cloud per VNC. SWIFT_EXEC_JOBS auf M4 vorsichtig erhöhen. Runner und VNC nicht gleichzeitig vollballern – Kapazität.
7) Miete für die zweite Build-Kiste
Wochenmiete vor Release, Monat für CI. Preise, TCO. Voller Remote-Desktop: Cloud-Mac mieten.
8) Typische Fragen
Langsamer? Klicks ja; Builds >10 Min. oft schneller auf Cloud-M4. Hybrid gewinnt.
Nur Windows? Ja – Artikel.
vs VPS? App-Store-Signierung → dediziertes Apple Silicon.
Sicherheit? Wie Mac mini im Büro: SSH-Keys, kein p12 in Git.
Erstes Archive? Nachmittag wenn routiniert; Hilfezentrum.
Alter Mac? Ohne lokalen Full Build behalten; Cloud für Compile-Spitzen.
Was ich produktiv nutze (zum Vergleich)
Build-Host: dedizierter M4 Mac mini bei Nuvcloud (SSH/VNC, Tag/Woche/Monat), keine geteilte macOS-VM.
Tagesmiete auf echtem Repo, Archive stoppen — Preise & Regionen · starten