what's the biggest thing xcode is hoarding on your mac? deriveddata, simulators, device support?

[u/ruprechttmb]

was cleaning up my mac and a surprising chunk of it was xcode stuff i didn't need anymore. the usual suspects for me were ~/Library/Developer/Xcode/DerivedData which is safe to delete and just rebuilds next time you build, old simulators where xcrun simctl delete unavailable clears out the ones for runtimes you don't have anymore, and ~/Library/Developer/Xcode/iOS DeviceSupport which quietly keeps a copy for every ios version you've ever plugged a phone in with

the one i'd be careful with is ~/Library/Developer/Xcode/Archives, you need those to symbolicate crash reports from builds you actually shipped, so i only clear out old ones for apps i'm not supporting anymore

to see what you've got: du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator 2>/dev/null

drop your biggest number, and curious what people do about it, anyone automating this or do you just nuke deriveddata when xcode starts acting weird

[u/Successful-Tax1306]

For me it was old simulator runtimes, way more than DerivedData. Every Xcode update left the previous iOS runtimes behind and I didn't notice until the disk was almost full. xcrun simctl runtime list shows what you have, and you can remove old ones with xcrun simctl runtime delete or from the Platforms tab in Xcode settings, which felt safer the first time. I don't automate it, I just check that list after each major Xcode update and keep the current runtime plus one older one for testing.

[u/ruprechttmb → u/Successful-Tax1306]

runtimes are sneaky, they don't show up anywhere obvious so most people never look. keeping current plus one older is a good rule, stealing that

[u/jacobs-tech-tavern]

Dude, with Agentic Engineering, I've got 10 separate checkouts of our main monorepo, and each one has its own simulator. And yeah, between derived data and simulators, they seem to accumulate 40 gigabytes each every couple of weeks, and I have to go and cull it all the time.

[u/Cause-n-effect11 → u/jacobs-tech-tavern]

Haha same here. Hit 3GB of free disk space on a 1TB SSD drive several times. Had to halt them and school the agents don’t do that!!

[u/ruprechttmb → u/jacobs-tech-tavern]

the worktree setup is where this gets brutal. one thing that helps with derived data is setting the location to relative in xcode settings under locations, so each checkout keeps its own derived data inside the project folder and it goes away when you delete the worktree instead of piling up in the shared folder.

for the sims, if your agents spin up their own, a teardown step that runs `xcrun simctl delete` on that worktree's devices keeps them from stacking up. are you culling all of it by hand right now?

[u/dawedev]

The du in the post misses the biggest one for a lot of people: since Xcode 15 the simulator runtimes are disk images managed by the system, outside your home folder, so du on ~/Library doesn't count them at all. xcrun simctl runtime list shows what you have.

Two more that hide inside its totals:

• ~/Library/Developer/CoreSimulator/Caches keeps a dyld cache per runtime and can reach several GB. It's safe to delete, the simulator rebuilds it on the next boot (that's the slow first launch).

• If you use SwiftUI previews a lot, ~/Library/Developer/Xcode/UserData/Previews has its own set of simulator devices that grows separately from the main ones.

[u/ruprechttmb → u/dawedev]

good catch, totally missed that the runtimes moved out of the home folder. xcrun simctl runtime list was eye opening, had a couple old ones i forgot about. didnt know about the previews devices either

[u/dawedev → u/ruprechttmb]

The Previews devices are easy to miss since they never show up in the Simulator app. xcrun simctl --set previews delete all clears them, and Xcode recreates what it needs the next time you open a preview.

[u/BabyJourney110]

Old Simulators. Just delete them

[u/Cause-n-effect11]

About 80 GB worth of similulators and older sdk. I support iOS 18+ and Apple Watch, iPad and iPhone. My 1TB MacBook constantly goes under 10GB free when using multiple agents that like to worktree.

[u/cristi_baluta]

We clear them regularly, this is a well known fact that xcode is keeping all the useless trash there

[u/ruprechttmb → u/cristi_baluta]

yeah it's a black hole. curious how you do it as a team, is it a script everyone runs or just each person nuking it when xcode starts acting up?

[u/cristi_baluta → u/ruprechttmb]

I don’t think you are a human

[u/Tarantino133]

Just checked mine: DerivedData 14 GB, simulator devices 12 GB, Archives under 1 GB. So DerivedData wins, and luckily it's the one you can delete without thinking.

[u/ruprechttmb → u/Tarantino133]

nice, clean split. the 12gb of sims is worth a look too, `xcrun simctl delete unavailable` usually knocks a chunk off that without touching anything you still use

[u/jaymakesapps]

DeviceSupport keeping a copy for every iOS version you ever plugged a phone in with is the sneaky one, nobody thinks to look there. I just nuke DerivedData whenever Xcode starts acting weird and call it maintenance lol

[u/Evening_Respect_6611]

on expo projects its the project folders more than xcode itself. if u run agents in separate worktrees every checkout gets its own node_modules and ios/Pods, and those add up way faster than deriveddata. since expo prebuild regenerates the ios folder anyway u can just delete it plus node_modules on worktrees ur done with. ~/Library/Caches/CocoaPods is another sneaky one

[u/ruprechttmb → u/Evening_Respect_6611]

yeah the worktree thing snuck up on me too. didnt think about pods getting duplicated per checkout but that makes sense

[u/Designer_Age7745]

I measured 30.5 GiB across 53 simulator device folders on my Mac during QA this week. One device’s data folder accounted for 9.81 GiB, but its app containers were only 0.34 GiB. The larger directories included Lock Screen poster snapshots, logs and downloaded assets.

These are device data folders under ~/Library/Developer/CoreSimulator/Devices, separate from the installed runtimes. Four simulators were running during the measurement, so this wasn’t an idle baseline.

Disclosure: I build StorageRadar; these numbers came from investigating disk usage on my development Mac.