Xcode Simulator neemt te veel ruimte in op je Mac? Wat je als eerste kunt opruimen

Als Xcode Simulator ruimte inneemt op je Mac, scheid dan simulator-runtimes van simulator-apparaatdata voordat je iets verwijdert. Begin met het bekijken van wat onbeschikbaar is, wat inactief is en wat je nog nodig hebt voor testen, want simulator-opruiming wordt riskant als je elke Apple-zijde map als wegwerpcache behandelt.

Dat is de fout die ontwikkelaars maken nadat ze één opruimregel hebben geleerd en die overal toepassen. DerivedData is het een. Simulator-runtimes en simulator-apparaatstatus zijn het ander.

De opslag kan worden teruggeclaimd. De consequenties zijn gewoon minder uniform.

Snel antwoord

Wat Xcode-simulators opslaan en waarom het oploopt

Simulator-opslag is niet één ding. Het zijn meerdere lagen die samen accumuleren.

Op een hoog niveau omvat Xcode-simulator-opslag meestal:

• runtime-images voor verschillende iOS-platformversies;
• aangemaakte simulator-apparaten voor verschillende iPhone- en iPad-modellen;
• per-apparaat app-data, instellingen en status binnen die simulators;
• Apple-zijde ontwikkelingschurn die groeit als je wisselt tussen SDK’s, apparaattypen en Xcode-versies.

Daarom voelen ontwikkelaars zich vaak in de war door CoreSimulator. Het is makkelijk om naar de mapgrootte te kijken en aan te nemen dat het hele ding gewoon cache is. In de praktijk is een deel meer als wegwerp-teststatus, en een deel is runtime-ondersteuning waar je nog van afhankelijk bent.

Het groeipatroon is normaal:

• je installeert een nieuwe Xcode of SDK;
• nieuwe runtimes verschijnen;
• nieuwe simulator-apparaten worden aangemaakt;
• apps, testdata en instellingen hopen zich daarin op;
• oude apparaten worden onbeschikbaar na SDK-wijzigingen of Xcode-upgrades;
• er maanden lang niets wordt beoordeeld omdat de machine nog genoeg vrije ruimte heeft.

Dan op een dag is simulator-opslag het verhaal, niet slechts een detail.

Simulator-runtimes vs simulator-data: Wat is het verschil?

Dit is het onderscheid dat er het meest toe doet.

Apple’s simctl-tooling behandelt runtime-operaties apart van apparaatoperaties. Dat alleen al vertelt je dat het opruimmodel gelaagd is: apparaten zijn niet hetzelfde als runtimes, en een apparaat wissen is niet hetzelfde als een runtime-image verwijderen.

Daarom zijn brede uitspraken als “maak CoreSimulator gewoon leeg” zwak advies. Ze vouwen verschillende opruimgevolgen samen tot één emotionele actie.

Waar DerivedData in past

DerivedData is aangrenzend, maar het is niet hetzelfde probleem.

DerivedData is over het algemeen gegenereerde build-output. Simulator-opslag is meer gemengd. Het kan runtimes bevatten die je nog nodig hebt, aangemaakte apparaten die je niet meer nodig hebt, en status binnen apparaten die je wel of niet belangrijk vindt.

Als de druk vooral uit gegenereerde build-output bestaat, is de juiste gids Xcode DerivedData Taking Too Much Space on Mac? What to Clean First. Als de druk vooral uit runtime-images en simulator-status bestaat, blijf dan bij de simulator-workflow.

Hoe je controleert hoeveel ruimte simulators innemen

De eerste zet is inspectie, niet verwijdering.

Gebruik Apple’s eigen tooling om te zien welke apparaten en runtimes er daadwerkelijk bestaan:

xcrun simctl list devices
xcrun simctl list runtimes

Als je de brede Apple-zijde opslagvoetafdruk op schijf wilt inspecteren, kun je de grote mappen ook direct vergelijken:

du -sh ~/Library/Developer/CoreSimulator
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/Archives

Dit is belangrijk omdat de grootste Apple-zijde map niet altijd degene is die je verwachtte. Soms is DerivedData het dominante probleem. Soms groeit CoreSimulator het ongemerkt voorbij.

Waar je als eerste naar moet kijken

• apparaten vermeld onder Unavailable;
• runtimes voor OS-versies die je niet meer test;
• veel aangemaakte apparaten over meerdere runtime-generaties;
• simulator-zware status op een machine die niet is schoongemaakt sinds meerdere Xcode-updates;
• een grote CoreSimulator-map die niet overeenkomt met je huidige testbehoeften.

Dat is het punt waarop opruiming rationeel wordt in plaats van reactief.

Is het veilig om simulator-runtimes te verwijderen op een Mac?

Soms wel, maar dit is niet de veiligste eerste zet.

Apple’s simctl runtime-hulp maakt duidelijk dat runtime-images hun eigen beheerde objecten zijn. Een runtime verwijderen is iets anders dan de inhoud van een simulator wissen. Het is ook iets anders dan een onbeschikbaar apparaat verwijderen.

Dat betekent dat runtime-verwijdering het beste werkt als:

• je die iOS-versie niet meer nodig hebt voor testen;
• je voorbij een oudere Xcode- of SDK-generatie bent;
• de runtime onbenut genoeg is dat de ruimte meer waard is dan het gemak;
• je de runtimelijst eerst hebt gecontroleerd en precies weet wat je verwijdert.

Het is een slechter idee als:

• een actief project nog steeds die runtime-familie target;
• SwiftUI-previews, QA-reproductiestappen of regressietesten er nog van afhankelijk zijn;
• je op het punt staat een issue te demoën of debuggen op een ouder target;
• je verwijdert op basis van grootte alleen in plaats van daadwerkelijke testbehoeften.

Betere eerste zet: verwijder het voor de hand liggende dode gewicht

De veiligste simulator-opruiming begint vaak met onbeschikbare apparaten.

Apple documenteert dit direct in simctl delete: de unavailable-alias verwijdert apparaten die niet worden ondersteund door de huidige Xcode SDK.

xcrun simctl delete unavailable

Dat is geen universeel antwoord, maar het is een van de schoonste eerste passes omdat het apparaten target die al als niet-ondersteund zijn gemarkeerd door je huidige SDK-context.

Simulator-data opruimen zonder je dev-omgeving te verliezen

Hier gebruiken ontwikkelaars vaak de verkeerde tool voor de taak.

Als je probleem verouderde app-data of opgeblazen apparaatstatus binnen simulators is, hoef je misschien helemaal geen runtimes te verwijderen. Je hoeft mogelijk alleen de simulator-apparaten te resetten.

Apple’s simctl erase-hulp definieert erase als het wissen van de inhoud en instellingen van een apparaat:

xcrun simctl erase <device>

Dat is een reset-operatie, geen runtime-verwijderingsoperatie.

Waar erase goed voor is

• app-state binnen een simulator wissen;
• testomgevingen resetten;
• opgeblazen apparaatniveau-inhoud verwijderen zonder het runtime-image zelf te verwijderen;
• de apparaatworkflow behouden terwijl de geaccumuleerde status wordt weggegooid.

Wat erase niet is

• geen runtime-opruimopdracht;
• geen DerivedData-opruimopdracht;
• geen goed alternatief voor het beoordelen welke apparaten en runtimes je daadwerkelijk nog nodig hebt.

Dat onderscheid is het hele simulator-opruimverhaal: een apparaat wissen, een apparaat verwijderen en een runtime verwijderen zijn drie verschillende beslissingen.

Hoe je simulator-opslag in de toekomst beheert

Het praktische doel is niet “simulators nooit laten groeien.” Het praktische doel is “voorkomen dat simulator-opslag onzichtbaar wordt.”

Gebruik een beoordelingsritme als dit:

1. Lijst apparaten en runtimes na belangrijke Xcode- of SDK-wijzigingen.
2. Verwijder onbeschikbare apparaten als ze verschijnen.
3. Reset verouderde simulator-apparaten als het probleem apparaatstatus is, niet runtime-inventaris.
4. Bekijk runtime-gebruik voordat je een OS-versie volledig verwijdert.
5. Vergelijk CoreSimulator, DerivedData en Archives samen als Apple-zijde opslag begint te stijgen.

Dat houdt de opruimbeslissing afgestemd op de laag die daadwerkelijk duur is.

Een beter mentaal model voor Apple-zijde opslag

• DerivedData is voornamelijk gegenereerde build-output.
• Archives bewaren deliverables en build-geschiedenis.
• CoreSimulator mengt runtime-ondersteuning met simulator-apparaatstatus.
• de veiligste opruiming hangt af van welke laag groot is, niet alleen welke map zichtbaar is.

Zodra je in lagen denkt, wordt simulator-opruiming veel minder chaotisch.

Waarom ontwikkelaarsopruiming beter werkt als het ecosysteem-bewust blijft

Als je alleen Finder gebruikt, ziet een Apple-zijde map van 20 GB of 30 GB eruit als één voor de hand liggend opruimdoel. Dat is het niet.

Een bestandsbrowser kan je laten zien dat CoreSimulator groot is. Hij kan je niet vertellen of de werkelijk vrij te maken ruimte bestaat uit:

• niet-ondersteunde apparaten;
• resetbare simulator-inhoud;
• runtimes die je niet meer nodig hebt;
• of een naburig Xcode-profiel dat toevallig in de buurt staat.

Daarom hoort simulator-opruiming binnen ontwikkelaarsopruiming, niet binnen generieke bestandsopruiming.

Als je werkelijke probleem “simulators plus DerivedData plus andere Apple-dev-opslag” is, is die bredere profiel-bewuste workflow veel nuttiger dan de ene mappad na de andere najagen.

Conclusie

Als Xcode Simulator ruimte inneemt op je Mac, behandel CoreSimulator dan niet als één wegwerp-cache-emmer.

Bekijk apparaten en runtimes eerst. Verwijder onbeschikbare apparaten als schone eerste pass, gebruik erase alleen als je simulator-inhoud en instellingen wilt resetten, en verwijder runtimes alleen als je die OS-versie werkelijk niet meer nodig hebt.

Dat is het veiligere opruimpad: scheid runtime-images van apparaatstatus, scheid simulator-opslag van DerivedData, en houd Apple-zijde opruiming gekoppeld aan daadwerkelijke testbehoeften in plaats van blinde mapverwijdering.