Plug a physical iPhone into a Mac running Xcode for the first time on a new iOS version, and Xcode quietly does something in the background before it will let you build to that device: it downloads and caches a set of debug symbols specific to that exact iOS version. Do this across a few devices and a few years of iOS updates, and you end up with a folder that nobody remembers growing, taking up a genuinely surprising amount of space.

What's actually in this folder

~/Library/Developer/Xcode/iOS DeviceSupport/ holds one subfolder per unique combination of device and iOS version you've connected and debugged against. The folder names look like iPhone14,3 17.4.1 (21E236) — model identifier, OS version, and build number. Inside each one, Xcode stores the debug symbols and support files specific to that OS build, which are required for Xcode to symbolicate crash logs and attach a debugger to a physical device running that exact version.

This is conceptually similar to why the simulator doesn't need this — simulators run on your Mac's own architecture with symbols Xcode already has locally, while a physical device runs Apple's shipped, stripped-down OS build, and Xcode needs the matching symbol set to make sense of what's happening on it.

Why it keeps growing

Every time you update an iOS device to a new version and then debug on it, Xcode adds a new entry — it does not remove the old one for the previous version automatically. Testing on both an iPhone and an iPad, each updated a few times a year, across a few years of ownership, easily produces a few dozen entries. Each one runs from a few hundred megabytes to over a gigabyte, so the folder as a whole commonly reaches into double-digit gigabytes for anyone who has owned test devices for a while.

Teams with a device lab — several physical iPhones and iPads kept specifically for testing across OS versions — see this multiply further, since each device and OS version pairing gets its own entry regardless of how similar the devices are.

What's safe to delete

Any entry for an iOS version you are not actively debugging against right now is safe to remove. If you've updated your test device to iOS 18 and have no reason to attach a debugger to a device still running iOS 16, the iOS 16 entry is pure historical residue. Xcode will simply re-download the matching support files the next time you connect a device running that OS version — which, if the device itself has moved on, may never happen again.

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

wipes the entire folder. Xcode re-downloads only what it needs, when it needs it, the next time you connect a device — the one caveat being that if a particular iOS version is old enough that Apple no longer serves those symbol files for fresh download, and you genuinely need to debug against a device stuck on that old version, deleting its entry could mean you can't easily get it back. This is uncommon in practice, since most developers debug against reasonably current iOS versions, but if you support a device fleet running older OS versions, delete selectively rather than wholesale.

Deleting selectively

To keep entries for OS versions you might still need while clearing clear historical clutter:

ls -la ~/Library/Developer/Xcode/iOS\ DeviceSupport/
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

Review the list, then remove specific folders by name:

rm -rf "~/Library/Developer/Xcode/iOS DeviceSupport/iPhone14,3 16.5 (20F66)"

This is a more careful approach for anyone maintaining device compatibility across a wide OS version range, at the cost of a bit more manual review.

The equivalent folders for other Apple platforms

If you develop for watchOS or tvOS as well, Xcode maintains parallel folders following the same pattern — watchOS DeviceSupport and tvOS DeviceSupport sit alongside iOS DeviceSupport in the same ~/Library/Developer/Xcode/ directory, and accumulate for exactly the same reason. Worth checking if you support Apple Watch or Apple TV apps, since they're easy to overlook once you've already dealt with the iOS folder.

Why Xcode needs this at all, in slightly more depth

It's worth understanding the underlying reason this folder exists rather than treating it as an arbitrary Xcode quirk. When you build and run on a physical device, the debugger (lldb) needs to be able to unwind the call stack and inspect variables inside not just your own code but also the system frameworks your app links against — UIKit, Foundation, and everything else Apple ships as part of the OS. Because the version of those frameworks running on the device is different for every iOS release, and because Apple ships them stripped of the symbol information a debugger needs (for size and security reasons), Xcode has to separately obtain and cache a matching symbol set for whichever exact OS build is running on the connected device before a debugging session can work properly.

This is also why deleting a DeviceSupport entry and then reconnecting a device running that same OS version triggers a visible "Preparing debugger support" step in Xcode before you can build and run again — it's re-fetching exactly what you deleted, and there's no way around that step once the local cache is gone.

A practical routine

  1. du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/* to see what's there and how large each entry is.
  2. Cross-reference against the iOS versions your currently owned test devices are actually running.
  3. Delete entries for OS versions no device you have access to is still running, unless you specifically need historical debugging capability for an old version.
  4. Repeat for watchOS DeviceSupport and tvOS DeviceSupport if relevant to your work.
  5. Revisit every six months or so rather than letting years of device updates accumulate before the first cleanup.

This is one of the lower-risk cleanups in the whole Xcode ecosystem — the data is genuinely re-downloadable in almost every practical case, and the failure mode (needing to debug against an unusually old OS version again) is rare enough that most developers never encounter it.

Where VolumeLens fits in

iOS DeviceSupport is exactly the kind of folder that grows for years without ever being deliberately created or noticed — nobody chooses to fill it, it just accumulates as a side effect of normal device testing. VolumeLens surfaces it in a scan sized honestly against Xcode's other caches, so a stale ten-gigabyte pile of old iOS symbol sets doesn't stay invisible simply because it lives three folders deep in ~/Library/Developer. See the free scan for yourself.