MacBook mit 256 GB für die Entwicklung: realistisch planen statt ständig löschen

Reicht ein MacBook mit 256 GB zum Programmieren? In Foren gehen die Antworten weit auseinander, von „problemlos“ bis „auf keinen Fall“. Beide Seiten haben ein Stück weit recht, denn die Antwort hängt weniger vom Gerät ab als von dem, was du darauf tust. Webentwicklung mit wenigen Projekten braucht anderen Platz als App-Entwicklung mit mehreren Simulator-Plattformen, Docker und Videoaufnahmen für den App Store. Diese Seite hilft dir, deinen eigenen Bedarf einzuschätzen und die vorhandene Kapazität bewusst zu verplanen.

256 GB sind Speicherplatz, nicht Arbeitsspeicher

Weil Suchanfragen wie „MacBook 256 GB RAM“ häufig auftauchen, vorab: Die 256 GB bezeichnen die interne SSD, also den dauerhaften Speicher für System, Programme und Daten. Der Arbeitsspeicher ist ein anderes Bauteil mit einer eigenen, deutlich kleineren Angabe. Beides lässt sich bei aktuellen MacBooks nachträglich nicht erweitern. Deshalb lohnt es sich, vor dem Kauf ehrlich zu planen und nach dem Kauf bewusst mit dem Platz umzugehen.

Was auf einem Entwickler-Mac Platz braucht

Neben macOS und deinen Programmen fallen bei der Entwicklung einige große Posten an: Xcode selbst und die Simulator-Plattformen, die du installierst, DerivedData mit Build-Ergebnissen und Indizes, Simulator-Geräte mit ihren Apps, bei Bedarf das Festplattenabbild von Docker Desktop, die node_modules deiner Projekte, Paket-Caches und schließlich deine eigenen Daten wie Projekte, Designs und Medien.

Außerdem braucht macOS freien Platz für Systemupdates und für Swap-Dateien, wenn der Arbeitsspeicher knapp wird. Eine SSD, die randvoll ist, macht den Mac spürbar träger, und manche Updates lassen sich dann gar nicht erst installieren. Plane deshalb immer eine Reserve ein, statt die letzten Gigabyte auszureizen.

Eine Beispielrechnung

Die folgende Tabelle ist eine Beispielrechnung mit angenommenen, gerundeten Werten. Sie ist keine Messung und keine Empfehlung, sondern zeigt, wie schnell sich einzelne Posten summieren. Setze für deine Planung deine eigenen Werte ein.

In diesem Beispiel ist die SSD praktisch voll, bevor ein zweites Xcode, eine weitere Simulator-Plattform oder ein größeres Videoprojekt dazukommt. Genau so erleben viele Entwickler einen 256-GB-Mac im Alltag: Es geht, aber es gibt keinen Puffer.

Deinen echten Bedarf messen

Statt Beispielwerten helfen dir deine eigenen Zahlen. Unter Systemeinstellungen → Allgemein → Speicher siehst du die grobe Verteilung. Genauer wird es im Terminal: du -sh ~/Library/Developer/* zeigt die Ordner von Xcode und Simulator, du -sh ~/.npm den npm-Cache. Welche Ordner auf einem Entwickler-Mac typischerweise wachsen und wie du sie einordnest, beschreibt die Seite Mac-Speicher voll: Systemdaten und Build-Ordner. Wiederhole die Messung nach ein paar Wochen, dann erkennst du, was schnell wächst.

Drei Zonen statt einem vollen Laufwerk

Ein 256-GB-Mac bleibt entspannter, wenn du deine Daten bewusst in drei Zonen teilst.

Intern: alles, was du täglich und auch unterwegs brauchst. Dazu gehören das System, deine Werkzeuge, das aktuelle Projekt und die Daten für die nächsten Tage.

Externe SSD: große Daten, die du brauchst, aber nicht überall. Typisch sind Archive, ältere Projekte, große Build-Ordner, Paket-Caches und Medienbibliotheken. Die SSD bleibt am Schreibtisch dauerhaft angeschlossen.

Löschbar: alles, was sich neu erzeugen lässt, etwa die node_modules ruhender Projekte, alte DerivedData-Ordner und Simulator-Geräte, die du nicht mehr nutzt. Wie du bei JavaScript- und Swift-Projekten vorgehst, zeigt die Seite node_modules und Paket-Caches.

Die Grenzen zwischen den Zonen verschieben sich mit deinen Projekten. Ein Projekt, das ruht, wandert von intern auf die SSD; eines, das wieder aktiv wird, kommt bei Bedarf zurück. Prüfe die Aufteilung deshalb alle paar Monate, zum Beispiel nach einem größeren Xcode-Update.

Drei typische Profile

Webentwicklung mit Node: Es gibt wenige sehr große Posten, dafür viele node_modules-Ordner. Wer ruhende Projekte regelmäßig aufräumt und ältere Projekte auf eine SSD legt, kommt mit 256 GB oft zurecht, solange Docker keine große Rolle spielt.

App-Entwicklung mit Xcode: Xcode, Simulator-Plattformen, DerivedData und Archive summieren sich schnell. Hier lohnt es sich, DerivedData und Archive auf eine SSD zu verlegen und nur die Simulator-Runtimes installiert zu lassen, mit denen du wirklich testest.

Full-Stack mit Docker: Das Festplattenabbild von Docker Desktop kann allein einen großen Teil der internen SSD belegen. Regelmäßiges Aufräumen in Docker gehört dann zur Routine, und das Abbild verlegst du bei Bedarf nur über die Einstellung von Docker Desktop.

Diese Profile sind eine grobe Orientierung, keine Messung. Deine eigenen Zahlen aus dem Terminal sind verlässlicher als jede Faustregel.

Fragen vor dem Kauf

Stehst du vor einem Neukauf, helfen ein paar ehrliche Fragen mehr als jede Tabelle. Wie viele Xcode-Versionen brauchst du gleichzeitig? Spielt Docker in deinem Alltag eine Rolle? Bearbeitest du Videos oder große Bildbestände auf dem Laptop? Arbeitest du oft unterwegs, ohne Schreibtisch und ohne externe SSD? Und wie viel Platz belegt dein jetziger Mac tatsächlich, nachdem du Regenerierbares abgezogen hast? Je öfter du mit Ja antwortest, desto eher lohnt sich mehr interner Speicher.

Wann 256 GB wirklich zu knapp sind

Es gibt Arbeitsweisen, bei denen auch eine gut organisierte externe SSD nur begrenzt hilft: mehrere Xcode-Versionen parallel, etwa für Betas, viele Simulator-Plattformen, große Docker-Setups oder Videobearbeitung direkt auf dem Laptop. Wenn du ohnehin einen neuen Mac kaufst und so arbeitest, ist eine größere interne SSD oft die einfachere Lösung. Eine externe SSD ergänzt die interne sinnvoll, macht dein Setup aber auch abhängiger von einem zusätzlichen Gerät.

Wo DevSpace Manager hilft

Für die mittlere Zone gibt es DevSpace Manager, eine macOS-App von BRUNIQO. Sie verlegt große Arbeitsordner wie Xcode DerivedData, Xcode-Archive, SwiftPM- und Node-Caches, node_modules, lokale Medienbibliotheken und große Projektordner auf eine dauerhaft angeschlossene externe SSD. Vor dem Umschalten vergleicht sie Quelle und Ziel vollständig, das Original bleibt bis zur gesonderten Freigabe als Quarantäne erhalten, und fehlt die SSD, blockiert die App Änderungen. Simulator-Runtimes und Docker.raw verlagerst du dagegen über die Einstellungen von Xcode und Docker Desktop.

Die Auslagerung ersetzt kein unabhängiges Backup. DevSpace Manager ist für den Mac App Store vorgesehen und derzeit noch nicht veröffentlicht. Mehr erfährst du auf der Seite zu DevSpace Manager.