1. Decide whether cleanup solves your problem
A project you have stopped working on is a better storage candidate than the project you rebuild all day. Removing its generated data can recover working room, but opening it again will create new files. The next build and indexing pass may take longer. Keep the cache if that saved work is more useful than the space.
If your goal is to fix a build error, read the error first. Apple’s Xcode team recommends checking settings and trying a clean build folder before deleting Derived Data reflexively. A duplicate build input, missing dependency or signing error can survive cache removal unchanged.
2. Confirm the project’s Derived Data location
For Xcode versions with a Locations pane, open Xcode → Settings → Locations and inspect the Derived Data path. Older releases call Settings “Preferences.” A custom workspace or build configuration can use a different location, so do not assume the default folder accounts for everything.
The usual default is ~/Library/Developer/Xcode/DerivedData. In Finder, choose Go → Go to Folder and paste that path to inspect it. Match the project name to the folder you intend to review, then use Get Info to check its size. Do not treat every similarly named folder as part of the same project.
3. Remove a reviewed selection
Save your work and stop builds, tests and previews. Quit Xcode before manually moving a selected project’s generated folder to Trash. If you have several Xcode versions open, close the sessions that may use that location. Keep the selection narrow enough that you can explain what it belongs to.
Xcode 27 adds a Delete Derived Data menu action, confirmed in Apple’s WWDC26 Xcode lab. If your installed version offers it, review the action’s scope and confirmation. Its presence is version dependent; this guide does not assume all releases have the same menu or that the action uses Trash.
4. Keep source, archives and test state separate
Do not extend this cleanup to the whole Library/Developer directory. Your project repository, release archives, simulator devices and platform runtimes serve different purposes. A release archive may be needed for distribution or debugging; a simulator may contain a test database that is not in source control.
Before removing a project folder, check for unusual workflows that saved an export or manually modified dependency inside generated storage. Copy anything you cannot reconstruct to a documented project location. A folder name is useful evidence, but it cannot prove that every file inside is replaceable.
5. Rebuild once and check available space
Reopen a project you still use and build it once. Confirm that its dependencies resolve and your expected work remains available. If you used Trash, review the removed contents before emptying it: the files still occupy space until permanent removal. Compare available storage after that step.
Avoid turning cleanup into an every-build ritual. If the folder immediately grows again, that is evidence of the project’s workload. Review inactive projects periodically, and investigate simulator runtimes separately when they are the larger contributor. ClearDisk can help inspect paths and sizes; deciding what development state to retain remains your choice.
References & further reading
These guides combine the linked official guidance with ClearDisk’s documented behavior. Your files and app settings determine the right next step.