Mac mini M4 im Praxistest:
Reicht die Leistung für große iOS-Projekte?

Sobald ein Team 500+ Swift-Dateien, 80+ Pods und 30+ CI-Läufe pro Tag hat, fragt die Beschaffung: Reicht der Mac mini M4? Brauchen wir M4 Pro? Oder warten wir auf M5? Auf Nuvcloud-Bare-Metal-M4-Clustern haben wir zwei Wochen lang drei anonymisierte Kundenprojekte verglichen: gleiche xcodebuild-Parameter, Xcode 16.4 stabil, gleiche DerivedData-Pfadstrategie. Im Folgenden: reproduzierbare Methodik und Stichprobendaten — kein Lab-Benchmark; bitte mit eigenem Repo verifizieren.

1) Definition: Was ist ein „großes iOS-Projekt“?

„Groß“ hat in der Branche keine einheitliche Definition. Wir ordnen Nuvcloud-Kunden in vier Stufen ein; die Daten unten beziehen sich vor allem auf Stufe L:

Liegt das Projekt in L oder XL und gleichzeitig Xcode-Indexierung + Simulator-UI-Tests laufen sollen, wird Speicher oft vor dem CPU-Modell zum Engpass — das wird häufig unterschätzt.

2) M4-Chip: Für Builds zählen CPU-Parallelität und Speicherbandbreite, nicht die GPU

Mac mini M4 (2024, Basis): 10-Core-CPU (4 Performance + 6 Efficiency), 10-Core-GPU, Unified Memory ab 16 GB (24 GB / 32 GB optional). Für xcodebuild gilt:

• Performance-Kerne für swift-frontend und clang — Xcode nutzt verfügbare Performance-Kerne standardmäßig voll; Efficiency-Kerne helfen bei I/O-Prefetch und Hintergrund-Indexierung.
• Unified Memory = Compiler-Heap + Linker-Working-Set + ModuleCache — 16 GB reichen oft beim reinen Build ohne Simulator; mit xcodebuild test und iOS-18-Simulator steigt die Kurve stark.
• Sequentielles SSD-Throughput ist selten der Engpass, Random I/O schon — DerivedData enthält Zehntausende kleine Dateien; NVMe im Mac mini reicht für große Projekte, aber ab 85 % Belegung verschlechtert sich P99 deutlich.
• GPU und Neural Engine tragen bei reinem Compile kaum bei; Core-ML-Konvertierung und Metal-Shader-Builds nutzen die GPU.

Gegenüber M3 bringt M4 in Geekbench Single-Core ca. 15 %; bei voll parallelisiertem Link fühlt es sich eher wie 10–20 % an. Apples Build-Efficiency-Guide empfiehlt weiterhin Modulaufteilung und explizite Abhängigkeiten — Hardware rettet keine zyklischen Dependencies.

3) Testmethode: drei Maschinen, zwei Projekte, ein Befehl

Hardware (Netzteil, macOS 15.5, Auto-Sleep aus):

• A: Mac mini M4 10-Core / 24 GB / 512 GB SSD (Nuvcloud Bare Metal, Rechenzentrum)
• B: Mac mini M2 Pro 10-Core / 16 GB / 512 GB SSD (Kunde, Büro)
• C: MacBook Pro M3 Pro 11-Core / 18 GB / 1 TB (Kunde, am Netzteil)

Projektstichproben:

• Proj-α (Stufe L): UIKit + SwiftUI, 86 CocoaPods, ein Scheme Archive, ca. 520 Swift-Dateien
• Proj-β (L+): modular + 2 Extensions + Flutter-Modul, ca. 680 Swift/ObjC-Dateien

Einheitlicher Befehl (Release / Device / ohne Tests):

Je 5 Läufe, P50, erster Lauf ausgeschlossen (Disk-Cache-Warmup). Temperatur und Netzwerk beeinflussen nicht den lokalen Build-Abschnitt, aber pod install — die Zahlen hier ohne Dependency-Download.

4) Cold-Start-Vollarchive: Wo M4 gewinnt

Proj-α Cold Start P50 (Sekunden → Minuten):

Proj-β (mit Flutter) vergrößert die Lücke: M4 P50 ~15.8 min, M2 Pro ~20.4 min. ios/Flutter und native Xcode-Targets konkurrieren um CPU; 24 GB halten M4 praktisch swap-frei, M2 Pro 16 GB zeigt in der Link-Phase gelegentlich Memory Pressure, P99 bis 24 min.

5) Inkrementelle Builds: das eigentliche M4-Stärkefeld

Etwa 80 % der Alltags-Builds ändern wenige Dateien. Mit behaltenem DerivedData, Proj-α, eine Swift-Datei geändert, inkrementelles Archive P50:

Xcode-Major-Upgrade oder Änderung von SWIFT_VERSION invalidiert ModuleCache — ein Grund, warum CI in der WWDC-Saison langsamer wird. Für CI gilt: DerivedData über Jobs hinweg erhalten schlägt M5-Wechsel; gleicher M4: ephemeral Disk P50 28 min, persistente Disk P50 9 min (siehe Beschleunigungsguide).

6) 16 GB / 24 GB / 32 GB: die richtige Wahl

Bei steigenden Speicherpreisen 2026 ist 24 GB der Sweet Spot für Stufe L. Bei 16 GB-Budget UI-Tests und Archive in Workflows auf verschiedene Runner-Labels legen — siehe Beta-/Produktions-Runner-Trennung.

7) Parallelität: die 10 M4-Kerne wirklich auslasten

Standard-xcodebuild liest verfügbare Kerne, aber große Projekte bremsen oft diese Einstellungen:

• SWIFT_COMPILATION_MODE = wholemodule explodiert den Speicher auf großen Targets — Modul-Splitting ist günstiger als mehr RAM.
• Unnötiges DEBUG_INFORMATION_FORMAT = dwarf-with-dsym in CI Release abschalten (lokal Debug behalten).
• -jobs explizit setzen: im Rechenzentrum oft -jobs 8 (2 Kerne für System und sshd), um OOM zu vermeiden.
• CocoaPods use_frameworks! :linkage => :static verkürzt Dynamic-Link-Zeit, verlängert ersten Build — Team-Trade-off.

Wenn Activity Monitor nur 4–5 volle swift-frontend-Prozesse zeigt, liegt es meist an seriellen Target-Abhängigkeiten oder einer riesigen Swift-Datei — Build Timeline (Xcode 16+) prüfen, nicht den M4 beschuldigen.

8) Zwei Lastmodelle: Entwicklungsrechner vs. 7×24-CI

Modell A · Remote-Entwicklungsbuild (siehe Schluss mit langsamem Xcode): dünnes lokales Gerät, SSH zum M4 für xcodebuild. Wichtig: inkrementelle Latenz und flüssiges VNC — 24 GB sind angenehmer.

Modell B · Self-hosted CI: GitHub Actions / GitLab Runner auf M4, Dutzende Läufe täglich. Wichtig: persistente DerivedData, SSD-Lebensdauer, Job-Warteschlange. 16 GB reichen oft; Engpass ist Queue, nicht Chip.

Flutter-Cache-Strategie: Flutter iOS CI. Signing-Pipeline mit Fastlane/TestFlight: Self-hosted CI-Guide.

9) Wann M4 Pro, zweiter Runner oder Cloud-Skalierung

Bei diesen Signalen lohnt sich mehr Maschinen statt mehr Kerne:

1. Cold Start P50 stabil >18 min und kurzfristig kein Modul-Split — XL-Governance statt nur Pro-Chip.
2. PR-Warteschlange am gleichen Runner >15 min — zweiter M4 16 GB horizontal skalieren schlägt einen M4 Pro.
3. 3+ parallele Simulator-UI-Tests — 32 GB oder dedizierte Testmaschine; Compile- und Test-Labels trennen.
4. Beschaffung, Strom, Ops begrenzt — Cloud-Bare-Metal-M4 tageweise testen; Runner-TCO: Sechs-Regionen-Vergleich.

M4 Pro (ab 12 CPU-Kerne) war in Proj-α nur ~8 % schneller beim Cold Start bei deutlich höherem Preis — ohne Video-Transcode oder lokales LLM: für iOS-Builds Runner-Anzahl vor Chip-Klasse.

10) Häufige Fragen

Kann Mac mini M4 16 GB große iOS-Projekte bauen? Ja, als dedizierter CI-Knoten; nicht gleichzeitig Xcode-GUI + zwei Simulatoren. Für Remote-Entwicklung 24 GB empfohlen.

Wie viel schneller als GitHub-hosted macOS? Reiner xcodebuild-Abschnitt oft nur 10–20 %; End-to-End hosted P50 25–45 min wegen Queue und kaltem Cache, self-hosted M4 8–12 min mit persistentem DerivedData.

Auf M5 Mac mini warten? Bei ephemeral CI-Disk oder 16-GB-Swap bringt M5 wenig. Wächst das Projekt >30 % Dateien/Jahr, Herbst neu bewerten; jetzt M4 + persistente Runner ist pragmatisch. Hintergrund: Warum M5 bei WWDC 26 fehlte.

Ersetzt eine macOS-VM Bare Metal? Signing, Performance-Core-Scheduling, Metal/Simulator sind in geteilten VMs unzuverlässig. Für echte Pipelines Bare-Metal-Mac mini — Vergleich: VM vs. echte Hardware.