Bei aktuellen MacBooks lässt sich die interne SSD nicht nachrüsten. Wer mehr Platz braucht, kauft beim nächsten Gerät größer ein oder erweitert jetzt mit einer externen SSD. Wie die Daten dorthin kommen, entscheidet darüber, ob die Lösung im Alltag trägt. Dieser Vergleich stellt vier Wege nebeneinander: Handarbeit im Terminal, die Einstellungen der Werkzeuge, Aufräum-Apps und DevSpace Manager. DevSpace Manager ist unser eigenes Produkt von BRUNIQO. Wir beschreiben es deshalb so nüchtern wie die anderen Wege, einschließlich seiner Grenzen.

Weg 1: Handarbeit mit mv und ln -s

Der klassische Weg besteht aus zwei Befehlen: mv verschiebt den Ordner auf die SSD, ln -s setzt am alten Ort einen Link. Das kostet nichts, ist vollständig nachvollziehbar und funktioniert mit jedem Ordner. Die Schwächen zeigen sich im Detail. Über Laufwerksgrenzen hinweg kopiert mv erst und löscht danach die Quelle, eine Prüfung der Kopie findet dabei nicht statt. Wird der Vorgang unterbrochen, musst du selbst herausfinden, was wo liegt. Und ob später die richtige SSD angeschlossen ist, prüft niemand.

Die bessere Variante der Handarbeit trennt die Schritte: kopieren, prüfen, Original umbenennen, Link setzen, testen und das Original erst später löschen. Wie das im Detail aussieht, zeigt die Schritt-für-Schritt-Anleitung. Sie braucht Zeit und Sorgfalt, aber keine zusätzliche Software. Für einen einzelnen, überschaubaren Ordner ist das oft völlig ausreichend.

Weg 2: Die Einstellungen der Werkzeuge

Viele Entwicklerwerkzeuge bringen eigene Einstellungen für ihre großen Datenordner mit:

  • Xcode legt unter Settings → Locations den Ort für DerivedData und Archive fest.
  • npm verlegt seinen Cache mit npm config set cache, pnpm seinen Paketspeicher über store-dir.
  • Docker Desktop ändert den Ort seines Festplattenabbilds unter Settings → Resources → Advanced → Disk image location.
  • Simulator-Runtimes verwaltest du in Xcode unter Settings → Components.

Dieser Weg ist offiziell vorgesehen, und das Werkzeug weiß selbst, wo seine Daten liegen. Das ist ein echter Vorteil. Die Grenzen: Du musst jedes Werkzeug einzeln einstellen, und Daten ohne eigene Einstellung bleiben außen vor, etwa Projektordner, node_modules oder Medienbibliotheken. Für Docker und Simulatoren ist dieser Weg trotzdem der richtige, weil ein roher Ordnerumzug dort riskant ist.

Weg 3: Aufräum-Apps

Aufräum-Apps löschen regenerierbare Daten wie Caches, alte Build-Ordner oder nicht mehr benötigte Simulator-Geräte. Das schafft schnell Platz und ist für eine einmalige Entlastung sinnvoll. Aufräumen ist aber kein Auslagern: Was gelöscht wurde, legen die Werkzeuge beim nächsten Build wieder an. Manche Aufräum-Apps sind auf Xcode spezialisiert, andere räumen das ganze System auf, und welche Daten sie als entbehrlich einstufen, unterscheidet sich. Achte bei jeder solchen App darauf, was genau sie entfernt. Archive mit Debug-Symbolen etwa sind kein Müll, sondern für die Auswertung von Absturzberichten wichtig.

Weg 4: DevSpace Manager

DevSpace Manager ist eine macOS-App von BRUNIQO, die große Arbeitsordner auf eine dauerhaft angeschlossene externe SSD verlegt. Du wählst Quelle und Ziel selbst aus. Ein Plan prüft Quelltyp, lokales externes Laufwerk, getrennte Volumes, freien Speicher und laufende Prozesse von Xcode, Simulator und Docker. Die App kopiert in einen Staging-Bereich, vergleicht Quelle und Ziel vollständig bis hin zu SHA-256-Prüfsummen, Symlink-Zielen, Rechten, Hardlinks und erweiterten Attributen und schaltet erst dann um. Das Original bleibt als Quarantäne für einen möglichen Rollback erhalten, ein Transaktionsjournal hält jede Phase fest, und eine Prüfung der Volume-Identität blockiert Änderungen bei fehlender oder falscher SSD.

Die Grenzen gehören dazu. Die SSD muss dauerhaft angeschlossen bleiben. Simulator-Runtimes, Docker.raw und Netzwerklaufwerke verschiebt die App bewusst nicht. Der Platz auf der internen SSD wird erst mit der gesondert bestätigten Freigabe des Originals frei. Ein Rollback reaktiviert den internen Stand vom Zeitpunkt des Umschaltens; Änderungen, die danach auf der SSD entstanden sind, werden nicht automatisch zusammengeführt. DevSpace Manager ist für den Mac App Store vorgesehen und derzeit noch nicht veröffentlicht.

Die vier Wege nebeneinander

KriteriumHandarbeitWerkzeug-EinstellungenAufräum-AppsDevSpace Manager
WirkungDaten liegen auf der SSDDaten des Werkzeugs liegen auf der SSDDaten werden gelöschtDaten liegen auf der SSD
Prüfung vor dem Umschaltennur, wenn du sie selbst machsthängt vom Werkzeug abentfälltvollständiger Manifest-Vergleich
Rückwegselbst organisiertEinstellung zurücksetzenDaten entstehen neu oder kommen aus dem BackupRollback aus der Quarantäne
Fehlende oder falsche SSDfällt erst beim Zugriff aufhängt vom Werkzeug abnicht betroffenÄnderungen werden blockiert
Geeignet fürbeliebige Ordnernur Daten des jeweiligen Werkzeugsregenerierbare Datengroße Arbeitsordner, ohne Simulatoren und Docker.raw

Welcher Weg passt zu dir?

  • Nur DerivedData soll von der internen SSD weg: Die Einstellung in Xcode ist der einfachste Weg.
  • Docker oder Simulatoren belegen den meisten Platz: Nutze die Einstellungen von Docker Desktop und Xcode.
  • Du brauchst schnell Platz und die Daten sind regenerierbar: Aufräumen reicht, zumindest vorübergehend.
  • Du bist im Terminal sicher und willst einen einzelnen Ordner verlegen: Handarbeit mit Prüfung ist eine gute Wahl.
  • Du willst mehrere große Arbeitsordner mit Prüfung, Journal und Rückweg verlegen: Dafür ist DevSpace Manager gedacht.

Oft ist die beste Lösung eine Kombination, zum Beispiel Docker über seine eigene Einstellung und Projektordner per geprüftem Umzug. Antworten auf häufige Detailfragen sammelt die Seite Häufige Fragen zum Auslagern.

Worauf du bei jedem Weg achten solltest

Einige Punkte gelten unabhängig davon, wie die Daten auf die SSD kommen. Die SSD sollte schnell genug für den Zweck sein und direkt am Mac hängen, gerade wenn Build-Ordner darauf liegen. Ihr Name sollte eindeutig sein und sich später nicht ändern, weil Links und Einstellungen den Pfad enthalten. Nach jedem Umzug gehört ein Testlauf dazu: Projekt öffnen, bauen, testen und prüfen, ob Dateibeobachter Änderungen erkennen. Und du solltest vorher festlegen, welche Daten du unterwegs ohne SSD brauchst, denn die bleiben intern.

Aufräumen und Auslagern schließen sich übrigens nicht aus. Oft ist diese Reihenfolge sinnvoll: zuerst Regenerierbares löschen, damit du nichts Überflüssiges kopierst, dann das verlegen, was du wirklich brauchst.

Egal welcher Weg: das Backup

Das Auslagern ersetzt kein Backup, egal auf welchem der vier Wege es geschieht. Nach dem Auslagern liegt deine Arbeitskopie auf der SSD, und diese SSD kann ausfallen oder verloren gehen. Sorge dafür, dass sie in deine Sicherung einbezogen ist, bevor du Originale löschst. Mehr zu DevSpace Manager findest du auf der Übersichtsseite der App.

DevSpace Manager

Große Arbeitsordner auf eine dauerhaft angeschlossene SSD auslagern: mit Dateiprüfung, Transaktionsjournal und aufbewahrtem Original für einen möglichen Rollback.

Zur App ↗