Jak bezpiecznie usunąć Xcode DerivedData i deweloperskie pamięci podręczne

Czym jest DerivedData i dlaczego tak bardzo rośnie

Xcode przechowuje w DerivedData wszystko, co generuje z Twojego kodu źródłowego: pośrednie obiekty kompilacji, skompilowane produkty, pamięci podręczne modułów, indeksy symboli dla autouzupełniania i przechodzenia do definicji (Jump to Definition) oraz logi kompilacji. Domyślnie folder znajduje się w ~/Library/Developer/Xcode/DerivedData i zawiera osobny podfolder dla każdego projektu lub workspace’u otwartego kiedykolwiek w Xcodzie.

Rozrasta się, bo tak działa Xcode: tworzy folder w DerivedData dla każdego otwieranego projektu — także dla jednorazowych klonów, zbudowanych raz i nigdy więcej nieotwieranych — i sam z siebie ich nie usuwa. Każdy folder przechowuje osobne produkty kompilacji dla każdej konfiguracji i miejsca docelowego (Debug i Release, symulator i urządzenie), dlatego zmierz podfoldery projektów, zamiast zakładać z góry, ile miejsca odzyskasz na swoim Macu.

Wszystko, co się w nim znajduje, z definicji da się odtworzyć — właśnie to oznacza „derived” (pochodne). Usunięcie DerivedData nie narusza Twojego kodu źródłowego, ustawień projektu ani niczego, co jest pod kontrolą wersji. Jedynym kosztem jest czas: następna kompilacja każdego projektu będzie pełną, czystą kompilacją, a indeksowanie przez kilka minut znów będzie działać w tle.

Jak usunąć DerivedData

Polecenie Clean Build Folder w Xcodzie (Product > Clean Build Folder lub Shift-Command-K) czyści produkty kompilacji tylko bieżącego, otwartego projektu — przydaje się, gdy kompilacja zachowuje się dziwnie, ale na zajętość dysku prawie nie wpływa. Aby naprawdę odzyskać miejsce, usuń same foldery DerivedData: pokaż je z poziomu ustawień Locations w Xcodzie, przejdź do nich w Finderze albo usuń je w Terminalu. Wszystkie trzy sposoby dają ten sam efekt.

Usuwanie folderów pojedynczych projektów to opcja precyzyjna: zostaw DerivedData dwóch, trzech projektów, które kompilujesz codziennie, a foldery pozostałych usuń. Usunięcie całości to opcja szybka i również w porządku — po prostu płacisz koszt pełnej kompilacji wszystkich projektów naraz.

1. Najpierw zamknij Xcode. Usuwanie DerivedData przy uruchomionym Xcodzie może zaburzyć pracę indeksera, a pliki otwarte przez Xcode mogą nie usunąć się w całości.
2. Znajdź folder: w Xcodzie otwórz Settings > Locations i kliknij małą strzałkę obok ścieżki DerivedData, aby pokazać folder w Finderze. Możesz też w Finderze nacisnąć Command-Shift-G i wpisać bezpośrednio ~/Library/Developer/Xcode/DerivedData.
3. Posortuj podfoldery projektów według rozmiaru, zaznacz te, których chcesz się pozbyć (albo wszystkie skrótem Command-A), i przenieś je do Kosza. Kosz to bezpieczniejszy nawyk — jeśli zmienisz zdanie, natychmiast przywrócisz foldery.
4. Możesz też użyć Terminala: rm -rf ~/Library/Developer/Xcode/DerivedData usuwa wszystko za jednym razem. Przy bardzo dużych folderach to szybsze niż Finder, ale zanim użyjesz tego polecenia, przeczytaj uwagę poniżej.
5. Otwórz ponownie Xcode i skompiluj projekt. Pierwsza kompilacja każdego projektu potrwa zauważalnie dłużej, a na pasku aktywności przez jakiś czas będzie widoczny komunikat „Indexing” — oba koszty są jednorazowe.

Ostrożnie z rm -rf: polecenie omija Kosz i usuwa pliki trwale, bez możliwości cofnięcia. Wpisz ścieżkę dokładnie, przy tym zadaniu nigdy nie używaj sudo, a jeśli nie czujesz się pewnie w Terminalu, wybierz Findera — efekt jest ten sam, ale odwracalny.

Usuń stare środowiska uruchomieniowe symulatorów

Symulatory to często kolejna duża kategoria danych deweloperskich. Każde pobrane środowisko uruchomieniowe (runtime) iOS, watchOS czy tvOS zajmuje własne miejsce, a każde symulowane urządzenie przechowuje dane w ~/Library/Developer/CoreSimulator/Devices. Jeśli masz za sobą kilka aktualizacji Xcode’a, sprawdź środowiska dla wersji systemów, na których już nie testujesz.

Najszybciej zadziała wbudowane polecenie porządkujące: uruchom w Terminalu xcrun simctl delete unavailable. Usuwa ono każde urządzenie symulatora oznaczone jako niedostępne (unavailable) — głównie urządzenia osierocone po usuniętych środowiskach i starych wersjach Xcode’a — razem z aplikacjami i danymi w jego wnętrzu. Najpierw przejrzyj listę poleceniem xcrun simctl list devices, zwłaszcza jeśli masz zainstalowaną więcej niż jedną wersję Xcode’a.

Same środowiska znajdziesz w Xcodzie w Settings > Components (w Xcode 14–15: Platforms). Zobaczysz tam każde zainstalowane środowisko symulatora wraz z rozmiarem; zaznacz stare i je usuń. Zostaw tylko najnowsze środowisko dla każdej platformy, chyba że aktywnie testujesz na starszych wersjach systemu.

Pojedyncze symulowane urządzenia usuniesz też w Window > Devices and Simulators: przejdź na kartę Simulators, kliknij prawym przyciskiem urządzenie, którego nie używasz — choćby jeden z sześciu zdublowanych modeli iPhone’a z danymi ze starych testów — i wybierz Delete. Razem z urządzeniem znikają jego zapisane dane i aplikacje.

Archiwa, pliki DeviceSupport i pamięci podręczne

Archiwa gromadzą się w ~/Library/Developer/Xcode/Archives za każdym razem, gdy uruchamiasz Product > Archive, aby przygotować kompilację do dystrybucji. Każde archiwum zawiera pełną kompilację aplikacji wraz z symbolami debugowania dSYM — często od 100 MB do 1 GB. Przed usunięciem pamiętaj o kompromisie: to właśnie pliki dSYM w środku umożliwiają symbolikację raportów awarii dokładnie tej kompilacji. Zachowaj archiwa wersji wciąż dostępnych w App Store lub TestFlight (albo upewnij się, że App Store Connect ma ich dSYM), a resztę usuń — najbezpieczniej w Organizerze Xcode’a (Window > Organizer > Archives), gdzie przed usunięciem widzisz kontekst każdego archiwum.

Folder iOS DeviceSupport (~/Library/Developer/Xcode/iOS DeviceSupport) przechowuje symbole debugowania, które Xcode kopiuje z każdego fizycznego iPhone’a lub iPada, jaki kiedykolwiek podłączono do tego Maca — po jednym folderze na wersję iOS, zwykle 2–5 GB każdy. Foldery wersji iOS, na których nie działa już żadne z Twoich urządzeń, to czysty balast: usuń je, a jeśli kiedyś znów podłączysz urządzenie z tą wersją, Xcode po prostu ponownie skopiuje symbole (raz zobaczysz komunikat „Preparing debugger support”). Podobne foldery istnieją też dla urządzeń z watchOS i tvOS.

Xcode ma też własne pamięci podręczne w ~/Library/Caches/com.apple.dt.Xcode, a symulatory — w ~/Library/Developer/CoreSimulator/Caches. Zawartość obu folderów jest odtwarzana w razie potrzeby, ale czyść je tylko wtedy, gdy Xcode i aplikacja Simulator są zamknięte, a plików pamięci podręcznej CoreSimulator, których nie rozpoznajesz, nie ruszaj.

Pamięci podręczne menedżerów pakietów (SwiftPM, CocoaPods, npm, Homebrew)

Menedżery pakietów przechowują pobrane zależności, aby kolejne instalacje były szybkie. To przydatne, ale na komputerze, który przez lata obsłużył wiele projektów, takie pamięci podręczne mogą stać się dużą kategorią na dysku. Da się je odtworzyć, jednak przy następnej instalacji pakiety trzeba będzie pobrać ponownie.

Swift Package Manager przechowuje pobrane pakiety w ~/Library/Caches/org.swift.swiftpm, a rozwiązane kopie zależności (checkouts) każdego projektu znajdują się też w jego folderze DerivedData — czyszcząc DerivedData, usuwasz więc i je. Wspólną pamięć podręczną usuniesz w Finderze albo poleceniem rm -rf z tą ścieżką.

CocoaPods przechowuje pobrane pody w ~/Library/Caches/CocoaPods. Najczyściej opróżnisz tę pamięć wbudowanym poleceniem pod cache clean --all. Foldery Pods w Twoich projektach pozostają nietknięte; znika tylko pamięć podręczna pobrań.

Pamięć podręczna npm znajduje się w ~/.npm i na komputerze intensywnie używanym do pracy z JavaScriptem może zająć wiele gigabajtów. Opróżnisz ją poleceniem npm cache clean --force (npm wymaga tej flagi, bo pamięć podręczna sama się naprawia i zwykle nie trzeba jej czyścić; jej usunięcie jest bezpieczne — przy następnej instalacji pakiety zostaną po prostu pobrane ponownie). Użytkownicy pnpm mogą zamiast tego uruchomić pnpm store prune.

Homebrew gromadzi stare pobrania i nieaktualne wersje pakietów. Polecenie brew cleanup usuwa nieaktualne wersje i przestarzałe pobrania, a uruchomione dla wszystkich pakietów odinstalowuje też zależności, których nic już nie potrzebuje (chyba że ustawiono HOMEBREW_NO_AUTOREMOVE); brew cleanup --prune=all dodatkowo opróżnia całą pamięć podręczną pobrań. Jeśli chcesz najpierw zobaczyć listę tego, co zostanie usunięte, uruchom brew cleanup -n.

Zautomatyzuj to

Wszystko powyższe działa, ale deweloperskie śmieci to kierat: DerivedData wraca po tygodniu normalnej pracy, pamięci podręczne znów się zapełniają, a każda aktualizacja Xcode’a zostawia kolejne niepotrzebne środowisko. Jeśli nie chcesz co miesiąc powtarzać sześciu ręcznych procedur, właśnie tę część warto zautomatyzować — narzędziem, które pokazuje swój tok rozumowania, zamiast po cichu usuwać wszystko masowo.

AskClean traktuje pliki deweloperskie jako pełnoprawne kategorie: jedno skanowanie wylicza Xcode DerivedData osobno dla każdego projektu, stare środowiska symulatorów (odczytywane przez simctl, z zachowaniem najnowszego dla każdej platformy), pliki DeviceSupport oraz pamięci podręczne menedżerów pakietów npm, SwiftPM, cargo, uv i innych. Wychwytuje też nowszych pożeraczy miejsca — lokalne modele AI: modele Hugging Face pokazuje pojedynczo, a bibliotekę modeli Ollama jako jeden element; wszystkie są domyślnie niezaznaczone.

Każda pozycja ma wyjaśnienie — co to jest, czy da się to odtworzyć i ile kosztuje usunięcie — i nic się nie wykona, dopóki tego nie potwierdzisz. Potwierdzone elementy są usuwane trwale, a nie przenoszone do Kosza, dlatego przed potwierdzeniem przejrzyj każdy wybór; Twój kod źródłowy i biblioteka zdjęć nigdy nie są ruszane. To ta sama lista kontrolna co w tym poradniku, tylko bez godziny pracy w Terminalu.

Co da się odtworzyć, a czego nie

Ta tabela pokazuje granice bezpiecznego usuwania, a nie obiecuje konkretnej oszczędności. Zmierz zajętość dysku przed każdą operacją i po niej — skrypt audytu tylko do odczytu z poradnika o miejscu zajmowanym przez symulatory Xcode raportuje te foldery, niczego nie zmieniając.

FAQ