Bezpiecznie usuń Xcode DerivedData i pamięci podręczne deweloperów

Czym jest DerivedData i dlaczego robi się ogromne

DerivedData to miejsce, w którym Xcode trzyma wszystko, co wyprowadza z Twojego kodu źródłowego: pośrednie obiekty kompilacji, skompilowane produkty, pamięci podręczne modułów, indeksy symboli dla autouzupełniania i przeskoku do definicji oraz logi kompilacji. Domyślnie mieszka w ~/Library/Developer/Xcode/DerivedData, z osobnym podfolderem dla każdego projektu lub workspace'u, jaki kiedykolwiek otwierałeś.

Rośnie z powodu strukturalnego: Xcode tworzy folder DerivedData dla każdego otwieranego projektu — w tym jednorazowych klonów, które skompilowałeś raz i nigdy więcej nie tknąłeś — i nigdy żadnego z nich nie usuwa. Każdy folder trzyma osobne produkty kompilacji dla każdej konfiguracji i destynacji (Debug i Release, symulator i urządzenie), więc pojedynczy średni projekt potrafi zajmować kilka gigabajtów, a cały folder na roboczej maszynie deweloperskiej zwykle dochodzi do 20-50 GB.

Wszystko w nim jest z definicji odtwarzalne — to właśnie znaczy „derived”. Usunięcie DerivedData nigdy nie dotyka Twojego kodu źródłowego, ustawień projektu ani niczego pod kontrolą wersji. Jedynym kosztem jest czas: następna kompilacja każdego projektu to pełna czysta kompilacja, a indeksowanie przez kilka minut działa ponownie w tle.

Usuń DerivedData

Są trzy sposoby i wszystkie kończą w tym samym miejscu. Polecenie Clean Build Folder w Xcode (Product > Clean Build Folder albo Command-Shift-K) czyści produkty kompilacji tylko dla aktualnie otwartego projektu — przydatne przy naprawianiu dziwnej kompilacji, ale wskazówki zajętości dysku prawie nie rusza. Aby odzyskać realne miejsce, usuń same foldery DerivedData.

Usuwanie per projekt to opcja chirurgiczna: zostaw DerivedData dla dwóch-trzech projektów kompilowanych codziennie, a foldery całej reszty skasuj. Usunięcie całości to opcja szybka — też w porządku, tylko płacisz koszt pełnej odbudowy wszystkich projektów naraz.

1. Najpierw zamknij Xcode. Usuwanie DerivedData przy działającym Xcode może zdezorientować jego indekser, a pliki otwarte przez Xcode mogą nie usunąć się czysto.
2. Znajdź folder: w Xcode otwórz Settings > Locations i kliknij małą strzałkę obok ścieżki DerivedData, by pokazać go w Finderze. Albo w Finderze naciśnij Command-Shift-G i wpisz bezpośrednio ~/Library/Developer/Xcode/DerivedData.
3. Posortuj podfoldery projektów według wielkości, zaznacz te do skasowania (albo Command-A, by wziąć wszystkie) i przenieś je do Kosza. Najpierw Kosz to bezpieczniejszy nawyk — jeśli zmienisz zdanie, przywrócisz je natychmiast.
4. Zamiast tego z Terminala: rm -rf ~/Library/Developer/Xcode/DerivedData usuwa wszystko za jednym zamachem. Dla bardzo dużych folderów jest szybsze niż Finder, ale przed użyciem przeczytaj uwagę poniżej.
5. Otwórz Xcode ponownie i skompiluj. Licz się z tym, że pierwsza kompilacja każdego projektu potrwa zauważalnie dłużej, a na pasku aktywności przez chwilę będzie widoczne „Indexing” — oba koszty są jednorazowe.

Ostrożnie z rm -rf: omija Kosz i usuwa bezpowrotnie, bez cofnięcia. Wpisz ścieżkę dokładnie, nigdy nie uruchamiaj tego z sudo do tego zadania, a jeśli Terminal to nie Twój żywioł, droga przez Finder robi to samo — odwracalnie.

Wyczyść stare środowiska symulatora

Symulatory to zwykle drugi po DerivedData pożeracz miejsca deweloperskiego. Każde pobrane kiedykolwiek środowisko iOS, watchOS czy tvOS zajmuje 5-8 GB, a każde symulowane urządzenie trzyma własny folder danych w ~/Library/Developer/CoreSimulator/Devices. Jeśli masz za sobą kilka aktualizacji Xcode, prawdopodobnie leżą u Ciebie środowiska wersji iOS porzuconych lata temu.

Najszybsza wygrana to wbudowane polecenie porządkujące: uruchom w Terminalu xcrun simctl delete unavailable. Usuwa ono każde urządzenie symulatora, którego środowisko nie jest już zainstalowane — sieroty po starych wersjach Xcode — i nie dotyka niczego, z czego wciąż możesz korzystać.

Same środowiska znajdziesz w Xcode w Settings > Platforms (w starszych wersjach Xcode zakładka nazywa się Components). Zobaczysz każde zainstalowane środowisko symulatora z jego rozmiarem; zaznacz stare i usuń. Zostaw tylko najnowsze środowisko na platformę, chyba że aktywnie testujesz na starszych wersjach systemu.

Możesz też przyciąć pojedyncze symulowane urządzenia w Window > Devices and Simulators: przełącz na zakładkę Simulators, kliknij prawym przyciskiem dowolne urządzenie, którego nigdy nie używasz — te sześć 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 wsparcia urządzeń i pamięci podręczne

Archiwa gromadzą się w ~/Library/Developer/Xcode/Archives za każdym razem, gdy uruchamiasz Product > Archive, by dystrybuować kompilację. Każde archiwum zawiera pełną kompilację aplikacji plus jej symbole debugowania dSYM — często 100 MB do 1 GB od sztuki. Zanim usuniesz, poznaj kompromis: dSYM-y w środku pozwalają symbolizować raporty awarii dokładnie tej kompilacji. Zachowaj archiwa wersji wciąż żywych w App Store lub TestFlight (albo upewnij się, że App Store Connect ma te dSYM-y), a resztę usuń — najbezpieczniejsza droga to Organizer w Xcode (Window > Organizer > Archives), gdzie przeglądasz i usuwasz je z pełnym kontekstem.

iOS DeviceSupport w ~/Library/Developer/Xcode/iOS DeviceSupport trzyma symbole debugowania, które Xcode kopiuje z każdego fizycznego iPhone'a lub iPada, jaki kiedykolwiek podłączono — 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 skopiuje symbole ponownie (raz zobaczysz „Preparing debugger support”). Analogiczne foldery istnieją też dla urządzeń watchOS i tvOS.

Xcode trzyma też własne pamięci podręczne w ~/Library/Caches/com.apple.dt.Xcode, a symulatory swoje w ~/Library/Developer/CoreSimulator/Caches — obie można bezpiecznie wyczyścić, gdy Xcode i aplikacja Simulator nie działają, i obie odbudowują się na żądanie.

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

Menedżery pakietów zachowują każdą pobraną kiedykolwiek zależność, by przyszłe instalacje były szybkie. To dobra inżynieria i zła higiena dysku: te pamięci podręczne tylko rosną, a na maszynie z kilkuletnim stażem projektów po cichu składają się na 10-20 GB. Wszystkie można bezpiecznie wyczyścić — w najgorszym razie następna instalacja pobierze pakiety ponownie.

Swift Package Manager buforuje pobrane pakiety w ~/Library/Caches/org.swift.swiftpm, a rozwiązane checkouty każdego projektu żyją też w jego folderze DerivedData — więc czyszcząc DerivedData, czyścisz i je. Wspólną pamięć podręczną usuniesz z Findera albo poleceniem rm -rf na tej ścieżce.

CocoaPods trzyma pobrane pody w ~/Library/Caches/CocoaPods. Czysty sposób na jej opróżnienie to wbudowane polecenie: pod cache clean --all. Foldery Pods Twoich projektów pozostają nietknięte; znika tylko pamięć podręczna pobrań.

Pamięć podręczna npm mieszka w ~/.npm i na maszynie ciężkiej od JavaScriptu potrafi sięgnąć wielu gigabajtów. Uruchom npm cache clean --force, by ją opróżnić (npm upiera się przy tej fladze, bo pamięć podręczna sama się naprawia i normalnie nigdy nie wymaga czyszczenia — jej usunięcie i tak jest całkowicie bezpieczne). Użytkownicy pnpm mogą zamiast tego uruchomić pnpm store prune.

Homebrew chomikuje stare pobrania i nieaktualne wersje pakietów. brew cleanup usuwa nieaktualne wersje i przeterminowane pobrania; brew cleanup --prune=all opróżnia dodatkowo całą pamięć podręczną pobrań. Jeśli chcesz najpierw zobaczyć listę tego, co zniknie, uruchom próbnie brew cleanup -n.

Zautomatyzuj to

Wszystko powyższe działa, ale deweloperskie śmieci to kierat: DerivedData wraca w tydzień normalnej pracy, pamięci podręczne się zapełniają, a każda aktualizacja Xcode osieroca kolejne środowisko. Jeśli wolisz nie powtarzać sześciu ręcznych procedur co miesiąc, to jest ta część, którą warto zautomatyzować — narzędziem, które pokazuje swój tok rozumowania, zamiast po cichu kasować hurtowo.

AskClean traktuje pliki deweloperskie jako kategorie pierwszej klasy: jedno skanowanie rozpisuje Xcode DerivedData per projekt, stare środowiska symulatora (odczytywane przez simctl, z zachowaniem najnowszego na platformę), pliki wsparcia urządzeń oraz pamięci podręczne menedżerów pakietów dla npm, SwiftPM, cargo, uv i innych. Łapie też nowszych pożeraczy miejsca — pamięci podręczne modeli Hugging Face i Ollama — które wypisuje per model i domyślnie zostawia niezaznaczone.

Do każdej pozycji dołączone jest wyjaśnienie — co to jest, czy da się odbudować, ile kosztuje usunięcie — i nic się nie wykona, dopóki tego nie potwierdzisz. Usunięcia trafiają do Kosza, więc pomyłkowe kliknięcie cofasz jednym przeciągnięciem, a Twój kod źródłowy, dokumenty i zdjęcia pozostają nietknięte. To ta sama checklista co w tym przewodniku, tylko bez godziny pracy w Terminalu.

FAQ