Learn how to free up space hogged by Xcode in caches, derived data, archives and simulators!
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/19998365-understanding-and-managing-xcode-space
Learn how to free up space hogged by Xcode in caches, derived data, archives and simulators!
hey Keegan, my book chapters are playing catch-up with your tutorials!
here’s a tip my co-author Caroline Begbie told me about, for Big Sur:
Also, there’s the idea of moving the default DerivedData location so each project has its folder in its own file hierarchy. So when you delete the project, its derived data goes with it.
I assumed, perhaps incorrectly, that the derived data folder can’t be within the project folder for some technical reason. It would make so much more sense if it were automatically deleted when you deleted a project. Surely there is some reason why its not like that by default?
hi Elliot! It was a revelation for me, I only found out when our team lead wrote this about SwiftLint:
SwiftLint 0.43.0 (0.43.1 is current) changed the way it handles paths in a way that might break its behavior for some of you. If you, like me, put your DerivedData with the project rather than in a global location, you’ll encounter this problem.
when I’m writing a tutorial, I create multiple versions of the sample app. I eventually delete most of them, but their folders all remain in DerivedData. So I’ll definitely be using this trick:
Sure enough, when I rebuild the project, there’s a DerivedData folder in the outermost project folder!
Note: the default is Unique.
Oh, it’s perfectly fine to do that. I’ve been doing it since Xcode 4 or 5 days. I did it, then, out of self defense to make it easier to find and delete since that was a daily requirement.
Also, I find the following app very useful when it comes to some Xcode related stuff clean-up:
DevCleaner - DevCleaner for Xcode on the Mac App Store