# Oude iOS-simulatorruntimes op de Mac verwijderen

> Scheid simulatorapparaten van runtime-images, en verwijder ze daarna in Xcode of met simctl zonder archieven aan te raken die je nog nodig hebt.

Published: 2026-09-01 | Updated: 2026-10-18

Xcode-opslag is niet één cache. Platformruntimes, simulatorapparaten, DerivedData, DeviceSupport en Archives kunnen dicht bij elkaar op schijf staan, maar ze hebben verschillende eigenaren en heel verschillende herstelkosten.

Een gedownloade runtime kan meerdere gigabytes gebruiken. Een simulatorapparaat kan daarna apps, databases, Sleutelhanger-items en testfixtures bovenop die runtime verzamelen. De verkeerde laag verwijderen kan een snelle opschoning veranderen in een lange download, een volledige herindexering, of het verlies van de exacte staat die nodig is om een bug te reproduceren.

De veiligste regel is eenvoudig: meet de grote categorie, bepaal de eigenaar, en verwijder die via Xcode of `simctl`. Behandel niet de hele map Developer als wegwerpbaar.

## Begin met een opslaginventaris

Stop actieve builds voordat je iets verwijdert, en noteer wat je nog ondersteunt. Leg de Xcode-versies, platformversies, OS-versies van fysieke apparaten en releasearchieven vast die relevant blijven voor het huidige werk.

Gebruik **Xcode › Settings › Components** om geïnstalleerde platformcomponenten te zien. Apple documenteert dit als de ondersteunde plek om simulatorruntimes te downloaden en te verwijderen: [Downloading and installing additional Xcode components](https://developer.apple.com/documentation/xcode/downloading-and-installing-additional-xcode-components).

Voor een alleen-lezen inventaris op de opdrachtregel:

```bash
xcrun simctl list runtimes
xcrun simctl list devices
```

Gebruik daarna een schijfanalyzer om de brede categorieën onder `~/Library/Developer` en CoreSimulator te vergelijken. De grootte zegt waar je moet kijken. Die zegt niet wat veilig te verwijderen is.

| Opslagtype | Wat het bezit | Ondersteund opruimpad | Herstelkosten |
|---|---|---|---|
| Simulatorruntime | Een platform-OS-image zoals iOS 18 | Xcode Settings › Components | Download- en installatietijd |
| Simulatorapparaat | Apps en gegevens voor één virtueel apparaat | Simulator of `simctl` | Apparaatstaat wordt gewist |
| DerivedData | Buildproducten, indexen en tussenresultaten | Xcode Settings › Locations of een gekozen projectmap | Tijd voor opnieuw bouwen en indexeren |
| DeviceSupport | Symbolen en ondersteuningsbestanden voor OS-builds van fysieke apparaten | Selectieve controle na het checken van apparaat- en crashbehoeften | Kan offline debuggen of symboolondersteuning verliezen |
| Archives | Gebouwde app plus dSYM's en distributiemetadata | Xcode Organizer | Kan de bijpassende symbolen en de distribueerbare build verliezen |

## Runtime-images en simulatorapparaten zijn verschillend

Een runtime is de downloadbare systeemimage van iOS, watchOS, tvOS of visionOS. Een simulatorapparaat is een virtuele iPhone, iPad, Apple Watch, Apple TV of Vision Pro die op een van die images draait. Meerdere apparaten kunnen één runtime delen.

Dit onderscheid verklaart twee veelvoorkomende verrassingen:

- Een apparaat verwijderen wint niet per se de meerdere gigabytes van de runtime terug.
- Een runtime verwijderen kan elk apparaat dat ervan afhangt onbeschikbaar maken.

Apple onderscheidt de runtime ook van de gesimuleerde hardwareconfiguratie in de documentatie voor Safari-ontwikkelaars: [Adding additional simulators](https://developer.apple.com/documentation/safari-developer-tools/adding-additional-simulators).

## Verwijder oude runtimes via Xcode

Open **Xcode › Settings › Components**, bekijk elke geïnstalleerde platformversie, en verwijder alleen versies die geen actief project, testmatrix of ondersteuningsplicht meer nodig heeft.

Bewaar een runtime wanneer een van deze waar is:

- Het is de nieuwste geïnstalleerde versie voor een platform waarvoor je ontwikkelt.
- Een bug reproduceert alleen op die OS-versie.
- CI of een lokaal testplan noemt die runtime expliciet.
- Opnieuw downloaden zou werk op korte termijn onderbreken op een trage of gemeten verbinding.

De runtime via Xcode verwijderen laat CoreSimulator de eigen records bijwerken. Vermijd het handmatig verwijderen van mappen uit `/Library/Developer/CoreSimulator` of `/System/Library/AssetsV2`. Die mappen kunnen beheerde assets en records bevatten die een verwijdering in de Finder niet verzoent.

De controle bij Opschonen van Mole kan vervangen gedownloade runtimes tonen die Apple als verwijderbaar meldt. Bevestig je er één, dan vraagt Mole het pad `simctl runtime delete` van Apple om die te verwijderen. Het controleert de runtime opnieuw op het moment van verwijderen, bewaart de nieuwste runtime voor elk platform, en biedt geen opschoning aan terwijl Xcode of Simulator-tooling actief is.

## Verwijder onbeschikbare apparaten apart

Is een runtime weg, dan kunnen apparaatrecords die ervan afhingen blijven staan als onbeschikbare vermeldingen. Bekijk de lijst eerst, en verwijder daarna alleen die onbeschikbare records:

```bash
xcrun simctl delete unavailable
```

Deze opdracht verwijdert apparaatrecords. Die verwijdert geen runtime-images, en die verwijdert geen beschikbare apparaten die nog een werkende runtime hebben.

Gebruik voor een benoemd apparaat **Window › Devices and Simulators** in Xcode. Dat is makkelijker te controleren dan een map in de vorm van een UUID verwijderen, omdat de interface de apparaatnaam, het platform en de beschikbaarheid samen toont.

## Wis een apparaat wanneer het probleem teststaat is

Heeft een specifieke simulator verouderde appgegevens, een kapotte databasemigratie of een authenticatiestaat die je wilt resetten, start dat apparaat dan in Simulator en kies **Device › Erase All Content and Settings**.

Behandel dit als het wissen van een testtelefoon. De gedeelde runtime blijft geïnstalleerd, maar het gekozen virtuele apparaat verliest geïnstalleerde apps, containers, Sleutelhanger-items, databases, rechten en andere staat. Leg vóór het wissen logs vast of exporteer elke fixture die nodig is om het probleem te reproduceren.

Eén vers apparaat maken is vaak beter dan elke simulator wissen. Het geeft een schone vergelijking terwijl de falende staat behouden blijft tot de bug begrepen is.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/xcode-storage-map.webp" width="1360" height="454" loading="lazy" alt="De ontwikkelaarsmap van Xcode verdeeld in opnieuw op te bouwen caches, DerivedData en modulecache, en vastgelegde artefacten, DeviceSupport, Archives en simulators.">
  <figcaption>Xcode-opslag bevat opnieuw op te bouwen uitvoer en vastgelegde artefacten. Apparaten, runtimes, DeviceSupport en Archives horen niet als één cache te worden behandeld.</figcaption>
</figure>

## Ruim DerivedData per project op, niet uit reflex

DerivedData bevat buildproducten, indexen, logs en tussenstaat die Xcode opnieuw kan maken. Het is meestal minder riskant dan archieven, maar een volledige wisbeurt laat elk project opnieuw bouwen en indexeren.

Gebruik **Xcode › Settings › Locations** om de map DerivedData te tonen. Sorteer op grootte en wijzigingsdatum, en verwijder eerst de map van een oud of kapot project. Heeft maar één project verouderde indexen of een ongeldige buildcache, dan voegt het verwijderen van de gegevens van elk project stilstand toe zonder betekenisvol meer nuttige ruimte vrij te maken.

Open na de opschoning het betrokken project en verwacht dat de eerste build, codeaanvulling en zoekindex trager zijn. Die vertraging is de herstelkosten van de ruimte die je terugwon.

Voor een bredere werkwijze voor ontwikkelaarsopslag, inclusief package-caches en modulecaches, lees [hoe je Xcode-bestanden veilig opruimt](https://mole.fit/nl/blog/how-to-clean-up-xcode-mac).

## Behandel DeviceSupport als debugmateriaal

DeviceSupport bevat symbolen en ondersteuningsgegevens voor fysieke apparaten en OS-builds. Oudere vermeldingen kunnen groot zijn, maar leeftijd alleen bewijst niet dat ze nutteloos zijn.

Vraag voordat je een vermelding verwijdert:

1. Sluit ik nog een apparaat aan dat deze OS-build draait?
2. Kan ik een crash moeten inspecteren of symboliseren die van dat apparaat is vastgelegd?
3. Kan Xcode de vereiste ondersteuningsbestanden downloaden of opnieuw maken wanneer dat nodig is?

Is het antwoord onzeker, bewaar het dan tot het gerelateerde apparaat en het crashvenster voorbij zijn. Een schijfkaart kan een grote versiemap aanwijzen, maar Xcode en de debugbehoefte bepalen of die waarde heeft.

## Archives zijn geen cache

Een `.xcarchive` bevat de gebouwde app, dSYM's en distributiemetadata voor een specifieke build. De bijpassende dSYM kan essentieel zijn bij het symboliseren van een crash van een versie die al bij gebruikers staat.

Open **Window › Organizer › Archives** en bekijk archieven op product, versie, uploadstatus en datum. Bewaar elk archief dat bij een live release hoort, tenzij dezelfde symbolen en buildartefacten elders zijn opgeslagen en gecontroleerd. Verwijder verouderde lokale experimenten pas nadat je hebt bevestigd dat ze nooit zijn gedistribueerd.

De nuttige vraag is niet "is dit archief oud?" Het is "kan een gebruiker me nog een crash van deze build sturen?"

## Een herhaalbare opruimwerkwijze

Gebruik deze volgorde wanneer Xcode-opslag onverwacht groeit:

1. Stop actieve builds, Simulator en gerelateerde opdrachtregeltools.
2. Meet runtimes, apparaten, DerivedData, DeviceSupport en Archives apart.
3. Verwijder ongebruikte runtimes in Xcode Settings, te beginnen bij vervangen platformversies.
4. Voer `xcrun simctl delete unavailable` pas uit nadat je de apparaatlijst hebt bekeken.
5. Verwijder verouderde DerivedData van gekozen projecten en accepteer de kosten van opnieuw bouwen.
6. Beoordeel DeviceSupport tegen de behoeften van fysieke apparaten en crashdebuggen.
7. Beoordeel archieven in Organizer tegen elke versie die gebruikers nog kunnen draaien.
8. Meet opnieuw voordat je een volgende ronde doet.

Stop wanneer je genoeg ruimte hebt teruggewonnen. Opruimen hoort een specifiek opslagprobleem te beantwoorden, niet de verwijderde hoeveelheid te maximaliseren.

## Wat Mole wel en niet doet

Mole scheidt ontdekken van verwijderen. Analyse brengt DerivedData, CoreSimulator, DeviceSupport en Archives in kaart zodat je kunt zien welke categorie groot is. Opschonen kan door Apple gemelde vervangen runtime-images aanbieden en een gekozen image via `simctl` verwijderen na een verse veiligheidscontrole.

Mole wist geen beschikbare virtuele apparaten en verwijdert geen releasearchieven, en afgezien van de opnieuw te maken systeemcache van de simulator die in de veelgestelde vragen hieronder staat, verwijdert het geen CoreSimulator-mappen. Xcode blijft de eigenaar van componenten, apparaten en archieven, en jij blijft de eigenaar van de test- en releasegeschiedenis die ze bevatten.

## Veelgestelde vragen

### Wist het verwijderen van een simulator mijn projectcode?

Nee. Projectbroncode staat normaal buiten de simulator. Een virtueel apparaat verwijderen of wissen haalt de geïnstalleerde apps en teststaat van dat apparaat weg, dus bewaar alles wat nodig is om een bug te reproduceren.

### Waarom won het verwijderen van apparaten minder ruimte terug dan verwacht?

Meerdere apparaten kunnen één grote runtime delen. Apparaatgegevens verwijderen haalt de gedeelde platformimage niet weg. Controleer Xcode Settings › Components om te zien of een ongebruikte runtime de grotere laag is.

### Is het veilig om de hele map DeviceSupport te verwijderen?

Behandel die niet als een algemene cache. Beoordeel oude vermeldingen van OS-builds selectief, vooral als je nog een fysiek apparaat debugt of symbolen nodig kunt hebben die bij die versie horen.

### Kan ik elk Xcode-archief verwijderen na het uploaden naar de App Store?

Niet veilig als standaard. Het lokale archief kan de bijpassende dSYM en de exacte distribueerbare build bevatten voor een versie die gebruikers nog draaien. Bewaar het tenzij die artefacten elders zijn bewaard en gecontroleerd.

### Vindt Mole oude simulatorruntimes?

Mole kan vervangen gedownloade runtimes tonen die Apple als verwijderbaar meldt en gekozen runtimes via `simctl` verwijderen. De enige CoreSimulator-locatie die het zelf opruimt is de opnieuw te maken systeemcache in `/Library/Developer/CoreSimulator/Caches`, en alleen terwijl er geen simulator of opgestart apparaat draait. Het beslist niet welke actieve testruntime, simulatorstaat of welk releasearchief je nog nodig hebt.

---

Canonical HTML page: https://mole.fit/nl/blog/how-to-clean-up-ios-simulator-mac
Blog index for agents: https://mole.fit/nl/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
