If your Xcode builds have started crawling, or you keep hitting index errors with no logical cause, stale cache data is probably the culprit.
Knowing how to delete derived data in Xcode is one of those skills every iOS developer picks up eventually, usually after losing a solid arvo to a phantom build failure that clears up in 90 seconds flat.
This is not some obscure trick. Clearing DerivedData is the single most-searched Xcode troubleshooting step on both Stack Overflow and the Apple Developer Forums. As of 2026, with Swift projects growing heavier and packages multiplying, the problem has only become more common. The good news: the fix is still just as fast.
This guide walks through every method, what to expect when you do it, and when it will not actually solve your problem.
Why Your Xcode Builds Are Going Haywire
The Folder Most Developers Never Think About
Xcode stores build artifacts, compiled modules, index data, and intermediate files from every project you open. All of it lands in one location: ~/Library/Developer/Xcode/DerivedData.
Most developers never touch that folder. It just grows in the background, quietly consuming disk space, and for a while that is completely fine. Builds stay fast. Autocomplete works. Life is braw.
Then something snaps.
An autocomplete suggestion vanishes. A "Could not find module" error appears after a clean build. You restart Xcode, clean the build folder, restart again, and the problem follows you around.
What Is Actually Inside DerivedData
The folder holds four main types of data: build products (compiled code output from your app and frameworks), the module cache (pre-compiled Swift and Objective-C modules that speed up rebuild times), project index data (what powers code completion, jump-to-definition, and diagnostics), and build logs from previous sessions.
On an active machine, this folder hits 20GB without much effort. I have seen setups crack 50GB after running CI jobs locally for months without ever cleaning up. Stack Overflow threads from 2024 are full of developers discovering this for the first time and looking for something to blame.
View more: Android App development company.
How DerivedData Gets Corrupted in the First Place
The most common cause: a mid-build interruption. If you Force Quit Xcode while it is compiling, it may leave partial write operations behind. Xcode writes to DerivedData incrementally, and cutting that process off creates incomplete data the next build cannot parse.
Upgrading Xcode is the other main trigger. New Xcode versions often change the format of compiled modules, which makes old DerivedData from a previous version incompatible with the new build tools. This is why clearing DerivedData after a major Xcode update is a genuinely good habit.
Signs Your Cache Has Gone Bad
You probably need a cleanup if: Xcode's autocomplete has gone quiet or is suggesting things that make no sense, build times have doubled with no code changes, you are seeing "Could not find module" errors after a clean, or the indexing spinner in the top bar just runs and runs and never stops.
Real talk. Any one of those symptoms is reason enough. Try the fix before spending two hours debugging anything else.
How to Delete Derived Data in Xcode: Three Tested Methods
Method 1: Via Xcode Settings (Safest)
Open Xcode. Go to Xcode > Settings (called Preferences in older versions). Click the Locations tab. You will see a "Derived Data" field with the current folder path shown below it. Click the small arrow icon next to that path. Finder opens at the DerivedData folder.
Close Xcode first. Then select everything inside the DerivedData folder and move it to Trash.
The reason this is the safest method: Xcode shows you exactly where the folder lives before you delete anything. If you changed the default location in the past and forgot, this reveals where it actually is.
Method 2: Terminal Command (Fastest)
This is the one I use. Open Terminal and run:
rm -rf ~/Library/Developer/Xcode/DerivedData
Done. No confirmation prompt. No Finder navigation. The folder is gone.
Here is the kicker. This command is completely safe. DerivedData does not hold your source code, your git history, your project files, or your signing certificates. Xcode regenerates everything in that folder on the next build.
I close Xcode before running the command out of habit, though I have done it with Xcode open and never hit a problem. I might be wrong about whether that actually matters, but closing first is the canny move.
Method 3: Finder Navigation (Most Flexible)
Open Finder. Press Cmd + Shift + G to open the "Go to Folder" dialog. Type or paste:
~/Library/Developer/Xcode/DerivedData
Press Enter. You are now looking at every DerivedData subfolder Xcode has ever created on this machine.
This is the method to use when you want to delete the cache for just one project, not all of them. Each subfolder inside DerivedData is named after a project with a unique hash appended. Find the folder matching your project name and delete only that one. Heaps more targeted than nuking everything.
Comparing the Three Methods
| Method | Speed | Requires Terminal | Can Target One Project |
|---|---|---|---|
| Xcode Settings | Moderate | No | No |
| Terminal Command | Fastest | Yes | No |
| Finder Navigation | Moderate | No | Yes |
What Happens After You Delete DerivedData
Your First Build Will Be Slower Than Usual
Delete the folder and Xcode rebuilds from scratch on the next run. That first build will take longer than you are used to. How much longer depends on project size, but expect it to feel slow.
This is not a sign something went wrong. Xcode is recompiling modules, regenerating the index, and rebuilding all the cache data it just lost. By the second or third build, speed should be back to normal, and with a bit of luck, faster than before the cleanup.
The Index Rebuild Process
After launching Xcode with a fresh DerivedData folder, you will see the indexing spinner running in the activity area. Xcode is reading through your source files and rebuilding the symbol database it uses for autocomplete, diagnostics, and navigation.
On a large project this can run for several minutes. On a small one it wraps up fast. Let it finish before making major edits, otherwise you will get false errors clogging up the editor while the index is still incomplete.
One thing worth knowing: the indexing process and the build process are separate in Xcode. A clean build completing successfully does not mean indexing is done. If your app compiles fine but code completion is still broken, the index has not finished yet. Wait for the spinner to stop.
A Faster Alternative When You Are in a Rush
If you are mid-deadline and cannot afford a slow first rebuild after clearing DerivedData, try this instead: Product > Clean Build Folder (Shift+Command+K). This clears the build artifacts for your current project without wiping the entire DerivedData directory.
It is not as thorough, but it resolves a solid chunk of build errors in a fraction of the time. Good for when you need a partial reset without committing to the full cleanup.
Files You Are Not Going to Lose
Your Swift files are not in DerivedData. Neither are your assets, your project settings, your git history, or your provisioning profiles. Everything in that folder is generated content, built from your actual source files.
Think about it this way. DerivedData is a cache. Clearing it does not delete the original data. It just means the next request has to regenerate from source. You cannot permanently lose anything by wiping it.
"The DerivedData folder is Xcode's working memory. When a project starts misbehaving for no obvious reason, clearing it is the first thing I try. Takes 30 seconds and resolves more problems than you would expect."
— Paul Hudson, Creator, Hacking with Swift (hackingwithswift.com)
Beyond DerivedData: Other Caches and What Is Coming Next
Swift Package Manager Cache
If you use Swift Package Manager (and most iOS developers do in 2026), there is a separate cache at ~/Library/Caches/org.swift.swiftpm. It stores downloaded package sources and resolved dependency manifests.
This cache does not usually cause build errors, but it can grow large over time, and it can hold stale version data if you are switching between package versions frequently. Clearing it is simple:
rm -rf ~/Library/Caches/org.swift.swiftpm
Worth trying if package resolution is behaving oddly or throwing version conflicts you cannot explain.
A wee detail that trips people up: if someone on your team committed a Package.resolved change that conflicts with your local state, you will see package errors that look like cache corruption. They are not. Run File > Packages > Resolve Package Versions in Xcode before reaching for the delete command.
Simulator Data Cleanup
Simulator data lives at ~/Library/Developer/CoreSimulator/Devices. Do not delete this folder wholesale because it holds your simulator device states and installed test apps.
The proper approach: run xcrun simctl delete unavailable in Terminal. This removes all simulator runtimes that are no longer tied to a supported Xcode version, which is where most of the disk bloat accumulates.
Actually, before running that, use xcrun simctl list devices to see what you have. Anything tagged "unavailable" is a candidate for removal. The delete command handles those automatically. Better to see what you are deleting before committing.
What Xcode 16 Changes Mean for You in 2026
You might be wondering whether Apple is doing anything at a deeper level to reduce how often this kind of cleanup is even necessary.
The answer is yes. Xcode 16, released in September 2024, made explicit module builds the default for Swift projects. According to Apple's own release documentation, this is a structural shift in how the build system handles intermediate products, designed to reduce the amount of module recompilation on incremental builds.
Apple's developer sessions from late 2024 pointed toward build time reductions of 25 to 30 percent for mid-size Swift projects as the explicit module system matures through 2025 and 2026. If those numbers hold, clearing DerivedData will become a less frequent troubleshooting step over the next couple of years.
For right now, though, it is still a standard part of the iOS developer toolkit. Know the commands. Keep them handy.
@avanderlee (Antoine van der Lee, iOS developer and Swift educator at SwiftLee):
"Cleared DerivedData again after updating Xcode. Every major version bump messes with your index data. Make it a habit after each Xcode upgrade and save yourself the debugging session."
When Clearing DerivedData Does Not Fix the Problem
The Error That Keeps Coming Back
Let me explain. Clearing DerivedData fixes corruption in cached data. It does not fix problems that live inside your actual project files, your dependencies, or your build configuration.
If you delete DerivedData and the exact same error appears on the next build, the cache is not the problem. The issue is somewhere in your code or project setup. The cleanup just bought you one build of false hope.
Stop and read the full error message. The real cause is usually right there, if you look at it properly instead of hunting for something else to wipe.
Deeper Issues That Need a Different Fix
Some common problems that get misdiagnosed as DerivedData issues:
CocoaPods conflicts need pod install run fresh, not a cache wipe. A broken signing identity needs the Xcode signing settings fixed, not the cache cleared. A build phase script that is failing needs the script itself corrected. A corrupted workspace file sometimes needs the .xcworkspace or .xcodeproj deleted and recreated from scratch.
I reckon at least half the times a developer reaches for the DerivedData fix, one of those is the actual culprit. The cleanup might silence the error for a build or two. Then it comes back.
Stick with me on the diagnostic flow: delete DerivedData, run one full build, check if the error returns. If it does, stop looking at the cache and start reading the actual error output. That is where the answer lives.
As a last note, the same principle applies to AI trading bot for trading configurations and build automation scripts: when a tool misbehaves, cache is always worth clearing first, but it is rarely the final answer.
Common Questions About Deleting DerivedData in Xcode
Q: How often should I delete derived data in Xcode?
A: After every major Xcode version upgrade, and any time you see unexplained build errors or broken autocomplete. No need to clear it on a schedule otherwise. Xcode handles routine cleanup on its own. Manual deletion is for troubleshooting, not regular maintenance.
Q: Will deleting DerivedData delete my Swift code or project files?
A: No. DerivedData contains only generated and cached files. Your source code, assets, project settings, and git history live elsewhere and are not touched. You can delete DerivedData safely without backing anything up first.
Q: How do I delete derived data for just one Xcode project?
A: Navigate to ~/Library/Developer/Xcode/DerivedData in Finder. Each subfolder is named after a project with a unique identifier appended. Find the folder matching your project name and delete only that subfolder, leaving the rest untouched.
Q: Why is Xcode still slow to index after I cleared DerivedData?
A: Because the index has to be fully rebuilt from scratch. Xcode reads all your source files and reconstructs its symbol database. This is a one-time cost after clearing the cache. On large projects it can take several minutes. Let it complete before judging whether the fix worked.
Top comments (0)