Xcode opruimen zonder release-archieven te verliezen

Xcode spreidt opslag over build-uitvoer, indexen, archieven, apparaatondersteuning, simulatorapparaten en downloadbare platform-runtimes. Een deel is opnieuw te maken. Een ander deel is de enige kopie van een release-archief of de bijbehorende dSYM's. De veilige aanpak is elke categorie te meten, die waar mogelijk via Xcode te verwijderen, en artefacten te bewaren die bij versies horen die al zijn uitgebracht.

Een nuttige eerste snede is wat Xcode opnieuw kan bouwen te scheiden van wat alleen jij kunt vervangen. DerivedData en indexen zijn meestal opnieuw te bouwen als de bron, de afhankelijkheden en de toolchain er nog zijn. Simulatorapparaten kunnen unieke testdata bevatten. Archieven en hun dSYM's moet je ook bewaren wanneer ze horen bij software die al bij gebruikers staat.

Waar de gigabytes van Xcode naartoe gaan

Begin bij de twee belangrijkste wortels op gebruikersniveau:

du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator 2>/dev/null | sort -h

De gebruikelijke zwaargewichten zijn:

• DerivedData: buildproducten, indexen en modulecaches, meestal één map per project. Het is opnieuw te bouwen, maar alles legen maakt de volgende indexering en builds duur. Pak eerst het verouderde project aan.
• DeviceSupport: symbolen en ondersteuningsartefacten die zijn vastgelegd voor fysieke apparaten en OS-builds. Oude items kunnen nog nuttig zijn om crashes te symboliseren.
• Archives: bewaarde builds van elke keer dat je een app hebt geëxporteerd of uitgebracht. Apple zegt het archief van elke build die je verspreidt te bewaren, omdat de binaries en de bijpassende dSYM-bestanden later nodig kunnen zijn om crashrapporten te onderzoeken. Archieven van builds die je Mac nooit hebben verlaten, zijn de veiligere kandidaten om op te ruimen.
• Simulatorapparaten en platform-runtimes: apparaten staan onder CoreSimulator, terwijl downloadbare runtimes als Xcode-componenten worden beheerd. Het is niet één cache.

Elk onderdeel veilig legen

DerivedData pak je het best per project aan. Sluit Xcode, gebruik Xcode > Settings > Locations om Derived Data te tonen, herken de map van het verouderde project en verplaats die map naar de prullenmand. Leeg alles alleen wanneer een globaal index- of buildprobleem de kosten van opnieuw bouwen rechtvaardigt.

Niet-beschikbare simulatorapparaten hebben een eigen opdracht. Die verwijdert hun apparaatgegevens, niet alleen een lijstregel, dus bewaar testdata die je nog nodig hebt voordat je de opdracht draait:

xcrun simctl delete unavailable

Dit verwijdert apparaatrecords waarvan de runtimes niet beschikbaar zijn. Het verwijdert de runtime-images zelf niet. Gebruik Xcode > Settings > Components om geïnstalleerde platforms en simulator-runtimes met hun terug te winnen groottes te bekijken, en verwijder daarna runtimes die je opnieuw kunt downloaden. De componentengids van Xcode van Apple documenteert hetzelfde beheerde verwijderpad. Gebruik Window > Devices and Simulators voor apparaatrecords.

Bekijk Archives in Window > Organizer. Bewaar het archief en de dSYM van elke verspreide build, ook oudere productieversies die nog in gebruik zijn. De gids over debuginformatie van Apple merkt op dat binaries en dSYM's alleen samen werken wanneer hun build-UUID's overeenkomen. DeviceSupport verdient ook een selectieve controle, geen algehele wisactie.

Sluit Xcode voordat je DerivedData verplaatst, zodat indexen en builddatabases niet midden in een schrijfactie zitten. Verwacht dat de volgende keer openen en bouwen opnieuw indexeert, afhankelijkheden oplost en uitvoer opnieuw maakt. Hoe lang dat duurt hangt af van het project en van wat er nog beschikbaar is.

Onder de motorkap: waarom DerivedData veilig is en DeviceSupport iets anders is

DerivedData is reproduceerbare build- en indexuitvoer. Voor elk project maakt Xcode een map met een hash van het projectpad, en vult die met gecompileerde objecten, modulecaches, indexen en buildproducten die zijn afgeleid van bron, instellingen, toolchains en afhankelijkheden. Verwijder die map en Xcode bouwt opnieuw wat er nog beschikbaar is. Dat kan tijd en netwerktoegang kosten. DeviceSupport is van een andere soort: wanneer je een fysiek apparaat debugt, legt Xcode ondersteunings- en symboolgegevens vast voor die OS-build. Simulatorapparaten en runtime-images zijn ook aparte beheerde objecten, geen gewone cachemappen. Archieven zijn de verzameling die je selectief wilt bewaren, omdat ze de dSYM's bevatten die je nodig hebt om crashrapporten van App Store-builds te symboliseren. Weten wat een opnieuw te bouwen cache is en wat een vastgelegd artefact is, is de hele grens tussen veilig legen en bewaren.

Waar een schijfkaart helpt

Een schijfkaart zoals de Analyseweergave van Mole kan laten zien of DerivedData, CoreSimulator of Archives de echte bron van de druk is. De weergaven Components, Devices en Organizer van Xcode horen de verwijdering uit te voeren, omdat zij runtimes, apparaten en release-artefacten begrijpen.

Een veilige volgorde

Stop actieve builds, meet Xcode en CoreSimulator apart, verwijder verouderde DerivedData per project, verwijder niet-beschikbare simulatorapparaten en verwijder ongebruikte runtimes via Components. Beoordeel Archives tegen uitgebrachte versies en wat je nodig hebt om te symboliseren voordat je ze verwijdert. Open één belangrijk project opnieuw en draai een build voordat je de prullenmand leegt.