What is the CoreSimulator Caches folder on a Mac, and what is safe to delete?

A Swift developer pinged me last week with a screenshot. Storage panel said 247 GB of System Data on a 1 TB MacBook Pro. He had already nuked DerivedData, deleted three Xcode versions, and run xcrun simctl delete unavailable twice. The number barely moved. The culprit, after a du pass, was ~/Library/Developer/CoreSimulator/Caches/ at 38.4 GB. That single Caches folder is the thing this post is about, because it is the simulator subdirectory Apple's tooling and most cleanup guides skip.

The CoreSimulator caches folder holds at least four distinct cache types, each generated by a different part of Xcode, each with a different rebuild cost. Treating it as a black box is how you leave 30 GB on the table or force a 9 GB re-download you did not need.

Where does the CoreSimulator Caches folder actually live?

The full path is ~/Library/Developer/CoreSimulator/Caches/. It is a peer of ~/Library/Developer/CoreSimulator/Devices/ (per-simulator data containers) and ~/Library/Developer/CoreSimulator/Volumes/ (mounted runtime bundles on newer Xcode). The three together make up the bulk of what shows under "CoreSimulator" in any disk audit.

Apple does not document the Caches subtree as a public surface. The folder names shift slightly between Xcode 15, 16, and the 17 beta. What stays constant is the role: shared, regenerable artifacts any simulator instance on the machine can reuse, keyed by runtime identifier.

On a representative Xcode 16.2 install with iOS 16, 17, 18, watchOS 10, and tvOS 17 SDKs present, the top-level listing looks like this:

ls -lh ~/Library/Developer/CoreSimulator/Caches/
# dyld/
# com.apple.coresimulator.runtime/
# downloads/
# org.apple.dt.Xcode/

Four entries, four very different stories.

What are the four caches inside CoreSimulator/Caches?

The dyld/ subfolder is the dominant entry in nine cases out of ten. It stores a prebuilt dyld shared cache for each runtime so the simulator launches in seconds instead of relinking on every boot. Each cache is roughly the size of the runtime's framework set: 700 MB to 1.4 GB for a single iOS version per architecture. Multiply by every iOS/watchOS/tvOS major version Xcode has pulled, then by arm64 plus x86_64 if you keep Rosetta and native sims, and the math gets ugly.

The com.apple.coresimulator.runtime/ folder is small. Skip it for cleanup. It rebuilds on first Xcode open.

The downloads/ folder is the surprise. When Xcode downloads a runtime via Settings > Components, the DMG is sometimes left behind even after the runtime mounts under Volumes/. That is duplicate storage. A 2024 thread on the Apple Developer Forums noted orphaned runtime artifacts in adjacent AssetsV2 paths that Xcode UI does not expose. Same pattern shows up here when an Xcode version is uninstalled before its runtimes are released.

The org.apple.dt.Xcode/ folder is the SwiftUI preview cache. Every #Preview render stores snapshots keyed by simulator UUID. Heavy SwiftUI work produces 4 to 8 GB. They regenerate on next preview.

How do I audit my own CoreSimulator caches folder?

Three read-only commands. None of them delete anything. Run them in a Terminal pointed at your user account.

# Top-level Caches breakdown, largest first
du -sh ~/Library/Developer/CoreSimulator/Caches/* 2>/dev/null | sort -hr

# Per-runtime dyld cache sizes
du -sh ~/Library/Developer/CoreSimulator/Caches/dyld/*/ 2>/dev/null | sort -hr

# Leftover runtime DMGs (the duplicate-storage surprise)
ls -lh ~/Library/Developer/CoreSimulator/Caches/downloads/ 2>/dev/null

# Preview cache total
du -sh ~/Library/Developer/CoreSimulator/Caches/org.apple.dt.Xcode 2>/dev/null

On my own Xcode 16.2 machine the dyld pass returned eight entries, largest a 1.7 GB iOS 18 arm64 cache. The downloads folder had a single 6.1 GB iOS 17.5 DMG the runtime install had not cleaned up. Preview cache was 2.3 GB. Total Caches footprint: 19.4 GB, with 6.1 GB reclaimable in one delete.

If the dyld total looks small compared to the parent Caches/ size, look for runtime DMGs in downloads/ first. That is where the easy wins hide.

What is safe to delete from CoreSimulator/Caches?

The risk classes break down clean. Treat the table as the floor, not the ceiling.

What is not in this table is the Devices/ and Volumes/ peers. Those are not caches. Treat them as out of scope here. The companion piece on reclaiming disk from Xcode simulators walks through the per-device deletion path with xcrun simctl.

For the items marked safe, the operative command is Move to Trash, not rm -rf. The reason is reversibility: if you delete a dyld cache for a runtime that turns out to also be required by an SDK you forgot was pinned, you want a one-click restore. The Finder Trash gives you that. A safety overview lives in the move-to-trash vs rm -rf comparison.

A safe per-subpath sweep using Finder's Trash from Terminal:

# Helper: send to Finder Trash via osascript, not rm
trash() {
  for f in "$@"; do
    osascript -e "tell app \"Finder\" to delete POSIX file \"$(realpath "$f")\""
  done
}

# Reclaim leftover runtime DMGs (audit the list first)
ls -lh ~/Library/Developer/CoreSimulator/Caches/downloads/
trash ~/Library/Developer/CoreSimulator/Caches/downloads/*.dmg

# Reclaim preview cache
trash ~/Library/Developer/CoreSimulator/Caches/org.apple.dt.Xcode

# Reclaim dyld caches for runtimes you no longer have installed
# (compare against `xcrun simctl list runtimes` before deleting any one)
xcrun simctl list runtimes
trash ~/Library/Developer/CoreSimulator/Caches/dyld/<obsolete-runtime-id>

The realpath call resolves the symlinks Apple sometimes leaves under ~/Library/Developer/. Without it, AppleScript's Finder bridge will occasionally refuse to delete a path that looks unresolved.

Does xcrun simctl delete unavailable touch the Caches folder?

No, and this is the trap that sends people in circles. xcrun simctl delete unavailable walks the Devices/ subtree, finds device records whose runtime no longer resolves, and removes them. It does not enumerate Caches/, look at dyld/, or clean downloads/.

The result is users running simctl repeatedly and watching System Data barely change. The full mechanics of what simctl delete unavailable actually touches are documented in the xcrun simctl delete unavailable guide.

Why does this folder grow back?

Because every part of it is regenerative by design. Boot a simulator, the dyld cache rebuilds if missing. Open a SwiftUI preview, snapshots get cached. Install a runtime, the DMG sits in downloads/ until a cleanup pass that never runs.

The growth is bounded by how many runtimes you actually use. The problem is Xcode never trims caches for runtimes you stopped using. A developer on the same Mac since Xcode 13 carries dyld caches for iOS 15, 16, 17, and 18 even if they only build for iOS 17 today.

A January 2026 writeup of using Claude to free 200 GB from a full disk makes the point. After the first 150 GB came off in obvious places, the next 75 GB came from "asking what else." CoreSimulator/Caches is usually in that second round. Verbatim: "After the initial Docker/cache cleanup freed 150GB, going back and asking 'what else?' found another 75GB."

What about the OS-level runtime location at /Library/Developer/CoreSimulator?

A system-level CoreSimulator path at /Library/Developer/CoreSimulator/ (no tilde) holds runtime bundles shared across user accounts. It is not the same as the per-user Caches folder. Touching the system path requires sudo and breaks Xcode if you guess wrong. Leave it alone unless you are removing a runtime through Settings > Platforms. The orphaned-runtimes case is covered in the orphaned simulator runtimes guide.

Why CleanMyDev exists for this folder specifically

du, ls, and osascript will get you through this audit. They give you raw sizes and a Trash move. They do not label which dyld/ subfolder belongs to iOS 17.5 versus watchOS 10 versus tvOS 17. They do not tell you whether the runtime that owns the cache is still installed. They do not warn you that a downloads/ DMG is for a runtime not yet mounted.

CleanMyDev runs the same enumeration above, maps every cache subfolder to a runtime identifier and last-modified date, marks the ones whose runtime is no longer installed, and offers a per-row reclaim with Move-to-Trash as the default. One pass, with receipts. $9.99 lifetime, from the pricing page. The point is not that you cannot do this with shell; it is that doing it with shell every quarter is the kind of task that does not get done.

The argument for using a dedicated tool is the same as the argument for using any audit-first cleaner: the cost of getting it wrong is higher than the cost of running a labeled scan.

Related reading

• How do I reclaim disk from Xcode simulators?
• Finding and deleting orphaned simulator runtimes on a Mac
• The xcrun simctl delete unavailable guide