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 is CoreSimulator op de Mac?

CoreSimulator is de map die Apple beheert en waarin Xcode de simulator-runtimes en de gemaakte simulators bewaart om apps voor iOS, iPadOS, watchOS en tvOS te bouwen en te testen. Op de meeste Macs staat hij in ~/Library/Developer/CoreSimulator, en hij groeit zodra je runtimes toevoegt, apparaten aanmaakt en er app-data in verzamelt.

Het is geen gewone cache. De map mengt twee dingen: runtime-images waar je misschien nog van afhangt, en apparaatstatus die je in veel gevallen kunt resetten of verwijderen. Daarom heeft “CoreSimulator is tientallen gigabytes groot” meer dan één antwoord.

Kan ik de map CoreSimulator verwijderen?

Blind in één keer niet. Het grootste deel van de ruimte krijg je terug door de juiste laag te legen in plaats van het hele pad te wissen.

Wis je ~/Library/Developer/CoreSimulator met de hand, dan moet Xcode de simulatorstatus opnieuw opbouwen en verdwijnen runtimes die je nog nodig hebt. Het veilige equivalent laat Apple’s eigen simctl weghalen wat echt wegwerpbaar is:

• verwijder apparaten die de huidige SDK niet meer ondersteunt met xcrun simctl delete unavailable;
• reset inhoud en instellingen van een apparaat met xcrun simctl erase <device> als opgeblazen app-status het probleem is;
• verwijder een runtime met xcrun simctl runtime delete alleen wanneer je die OS-versie niet meer test.

Ruimte in CoreSimulator win je laag voor laag terug, niet door de map te wissen en te hopen dat Xcode het overleeft.

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.

Simulators verwijderen in Xcode, stap voor stap

Wil je simulators verwijderen in plaats van alleen bekijken, dan heb je twee veilige routes: de Xcode-interface en de opdrachtregel met simctl. Beide halen oude simulators weg zonder runtimes aan te raken die je nog gebruikt.

Vanuit de Xcode-app:

1. Open Xcode en ga naar Window → Devices and Simulators.
2. Kies het tabblad Simulators.
3. Klik met rechts op een simulator die je niet meer nodig hebt en kies Delete, of gebruik Delete Unavailable Simulators voor apparaten die de huidige SDK niet meer ondersteunt.

Vanaf de opdrachtregel:

# eerst alles op een rij
xcrun simctl list devices

# verwijder alle apparaten die de huidige SDK als unavailable markeert
xcrun simctl delete unavailable

# verwijder één specifiek apparaat op UDID
xcrun simctl delete <device-UDID>

Onbeschikbare simulators verwijderen is de schoonste eerste ronde, omdat er alleen apparaten verdwijnen die Apple al als niet-ondersteund markeert. Verwijder je één apparaat, dan gaat die simulatorinstantie weg en blijft de runtime-image staan, dus je kunt hem later opnieuw aanmaken.

Wil je ruimte terugwinnen, begin dan hier voordat je aan runtimes denkt: een verwijderd apparaat maak je zo weer aan, een verwijderde runtime weegt zwaarder.

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.

Waar CoreSimulator op de schijf staat

Bij het doorlichten van simulatoropslag tellen twee paden.

~/Library/Developer/CoreSimulator/Devices bevat de simulators die je hebt aangemaakt. Elk apparaat is een map met zijn UDID als naam, en de data/ daarin draagt geïnstalleerde apps, app-data en instellingen. Dit is de laag die simctl erase reset en simctl delete weghaalt.

De map /Library/Developer/CoreSimulator op systeemniveau draagt de runtime-kant. Afhankelijk van je Xcode-versie staan de runtime-images onder Profiles/Runtimes als .simruntime-bundels, of beheert Xcode ze als downloadbare runtimes die xcrun simctl runtime list toont. Wat je daar weghaalt raakt elk gebruikersaccount op de Mac, dus behandel het als de zwaardere beslissing.

du -sh ~/Library/Developer/CoreSimulator/Devices
du -sh /Library/Developer/CoreSimulator
xcrun simctl runtime list

Domineert Devices, dan zit je probleem in opgebouwde apparaatstatus en in apparaten die de huidige SDK niet meer ondersteunt. Domineert de systeemmap, dan zit het in de runtime-images.

Kun je CoreSimulator naar een externe schijf verplaatsen?

Die vraag komt op als de interne schijf klein is en de simulatormap voorbij 40 GB gaat. Apple levert geen ondersteunde instelling om hem te verplaatsen, dus grijpen ontwikkelaars naar een symlink: ~/Library/Developer/CoreSimulator naar het externe volume kopiëren, de kopie controleren, het origineel weghalen en het oude pad aan het nieuwe koppelen.

Waar je ja tegen zegt:

• Xcode kan geen simulator starten als de schijf niet gekoppeld is, want het pad verdwijnt;
• op een USB-schijf zonder eigen voeding starten simulators trager dan op de interne SSD;
• een update van Xcode of de SDK kan delen van de mapstructuur op het oorspronkelijke pad opnieuw aanmaken;
• back-up en rechten werken anders op externe volumes.

Meet de terug te winnen ruimte voordat je de hele map verplaatst. Onbeschikbare apparaten en runtimes die je niet meer test leveren vaak meer op dan de verhuizing, en je houdt de opzet die Apple ondersteunt.

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.