Can You Delete Xcode iOS DeviceSupport? A Safe Cleanup Guide

What DeviceSupport actually contains

When Xcode debugs a physical iPhone, iPad, Apple Watch, or Mac, it needs support data for the operating-system build on that device. On Macs with older and current Xcode histories, you may find versioned folders under ~/Library/Developer/Xcode/iOS DeviceSupport and a sibling macOS DeviceSupport directory.

These files help Xcode understand system frameworks and symbols while attaching the debugger. They are not your app's source code, not Simulator devices, and not the matching dSYM for an app you distributed. Those three categories have different deletion costs, so a safe cleanup begins by keeping them separate.

The directory grows when you connect devices running different OS versions or builds. A developer who tests several phones across multiple release cycles can retain support data for versions no longer present in the current device lab.

Find the folders and build a keep list

Quit Xcode and disconnect devices before reviewing the folder. In Finder, press Command-Shift-G and enter ~/Library/Developer/Xcode. Look for iOS DeviceSupport and macOS DeviceSupport. The exact set of directories depends on which platforms, Xcode versions, and physical devices this Mac has used.

Switch Finder to list view and calculate folder sizes. Terminal users can run du -sh ~/Library/Developer/Xcode/*DeviceSupport* for a read-only summary. If a wildcard matches nothing, the shell may print an error; that simply means the corresponding directory is absent.

Now inventory the physical devices you still debug. On each device, check Settings > General > About for its software version, or connect it and inspect Window > Devices and Simulators in Xcode. Keep support folders that match the OS versions and builds in this active test matrix.

1. Quit Xcode and Simulator, then disconnect physical test devices.
2. Open ~/Library/Developer/Xcode in Finder and measure each DeviceSupport folder.
3. List the OS versions currently installed on every physical device you expect to debug.
4. Keep matching versions plus any near-term beta or compatibility target required by your team.
5. Move only unmatched, obsolete version folders to the Trash and leave the Trash unemptied until your next device-debugging check succeeds.

What happens after deletion

If you later reconnect a device whose support folder you removed, Xcode may display a preparation message while it restores or acquires the support it needs. Apple documented this copy-again behavior in an Xcode release-note workaround: after removing iOS DeviceSupport, reconnecting the device caused Xcode to copy symbols again.

That makes DeviceSupport broadly reconnectable, but not free to delete at every moment. Regeneration can take time, requires the device and compatible tooling, and may interrupt debugging when you are already under deadline. Keep the current lab versions instead of optimizing the folder down to zero.

For an old OS build you can no longer reproduce or reconnect, weigh the small chance of needing it against its size. The conservative option is moving the folder to external backed-up storage first. Restore it to the same directory if a legacy investigation later depends on it.

Apple's documented delete-and-reconnect instruction was a workaround for a specific Xcode release. Use it as evidence that support can be prepared again, not as a recommendation to erase every current DeviceSupport folder.

Do not confuse these four Xcode storage categories

DeviceSupport belongs to physical-device debugging. Simulator runtimes are platform images installed through Xcode Settings > Platforms, while individual simulated devices and their apps live under CoreSimulator. Removing DeviceSupport does not uninstall a Simulator runtime.

DerivedData contains project build products and indexes. It is recreated from your source and is normally the first Xcode category to clear for low-risk disk recovery. DeviceSupport is also recoverable in many cases, but only after Xcode prepares it again for the corresponding physical device.

Archives are the high-cost category. An .xcarchive can preserve the exact app binary and matching dSYM for a distributed build. Never delete an archive because its version number resembles an obsolete DeviceSupport folder. The names describe different artifacts.

When DeviceSupport is not the real space problem

A large Xcode directory does not prove DeviceSupport is the dominant category. Measure DerivedData, Archives, CoreSimulator, DocumentationCache, and DeviceSupport independently. Clearing a small symbol folder while leaving unused Simulator runtimes installed may save little and create unnecessary setup time.

If the startup disk is critically full, first create working room with reversible, rebuildable data: Trash, Downloads, old DerivedData, and unavailable Simulator devices. Then review DeviceSupport by OS version. Leave Archives for a deliberate release-retention audit.

Repeat the measurement after cleanup. macOS Storage settings can update slowly, whereas Finder folder sizes or du give a more direct before-and-after comparison. Avoid quoting a universal number of gigabytes: the recoverable amount is whatever your obsolete version folders actually occupy.

How AskClean makes the distinction visible

AskClean measures iOS and macOS DeviceSupport as separate Xcode items and places them in a cautious review flow. It does not merge them with DerivedData, and it does not present Archives as equivalent cache.

The scan explains that DeviceSupport has a later preparation cost and asks before moving anything to the Trash. Archives receive the stricter irreversible-cost treatment. This makes the decision visible, but your current physical-device test matrix remains the final authority.

DeviceSupport is one Xcode storage layer

Use location and recovery cost to avoid deleting the wrong artifact.

FAQ