Bytesweep 
先量一量
一条命令就能告诉你总量在 Xcode 各文件夹之间是怎么分的，你也就知道该先动哪一个：
du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator 2>/dev/null | sort -h六个文件夹
DerivedData —— 通常最大 · 可安全删除
构建中间文件、索引和模块缓存，每个项目一个文件夹，会一直保留，包括你早就删掉的项目。
~/Library/Developer/Xcode/DerivedData删除它的代价只是一次较慢的重新构建，仅此而已。它也是 Xcode 行为异常时的标准解法，所以每个 iOS 开发者都能背出这个路径。
iOS DeviceSupport —— 较大 · 可安全删除
从你连接过的每一台真机复制来的符号缓存，每个 iOS 版本一个文件夹。每个好几 GB，而且会为你早已不再拥有的手机不断累积。
~/Library/Developer/Xcode/iOS DeviceSupport下次你插上运行那个 iOS 版本的设备时，Xcode 会重新复制这些内容 —— 第一次连接会慢一些，此外没有别的代价。
CoreSimulator 设备 —— 较大 · 基本安全
每个模拟设备都有自己的文件系统，而且从不会被回收。请使用 Xcode 自己的命令，而不是直接删文件夹，以保持它的数据库一致：
xcrun simctl delete unavailable更进一步， xcrun simctl delete all 会移除所有模拟器设备。模拟器运行环境本身则在 Xcode → 设置 → 组件。
归档 —— 不大但无可替代 · 请保留
你发布过的每一个构建，连同它的 dSYM 调试符号。
~/Library/Developer/Xcode/Archives这一项请别动。 没有已发布构建的 dSYM，你就无法为正在使用该版本的用户的崩溃报告做符号化 —— 堆栈信息将永远停留在十六进制地址上。如果这里非清不可，请保留所有仍在流通版本的归档。
而且下一个 iOS 版本发布后还会再来一次
DerivedData 在你构建的那天就回来了，DeviceSupport 会随着你插上的每台设备增长，这更像是一件杂务而不是修复。Bytesweep 一次就能找出全部六个文件夹，把归档标记为待审阅而不是直接清理，并且任何清理都能在七天内撤销 —— 这在你清错了项目的那一天格外重要。
Swift Package Manager 缓存 —— 可安全删除
克隆下来的依赖仓库，会按需重新获取。
~/Library/Caches/org.swift.swiftpm旧的模拟器运行环境和旧版本 Xcode —— 谨慎处理下可安全删除
一个旧的 Xcode.app 本身就有 15 GB，它的运行环境还要再占几个 GB。保留你老项目仍然需要的那个版本；其余的通过访达删除，然后在「设置 → 组件」中移除它们关联的运行环境。
两个能把它压下去的习惯
按项目删除 DerivedData，而不是整个删光
每个子文件夹都以项目命名。清空整个文件夹会迫使你当前在做的所有项目重新构建；而清掉去年做完的项目对应的那些，则一点代价都没有。
每次 iOS 发布后检查 DeviceSupport
你连接的每台设备、每个 iOS 版本都会让它多出一个文件夹，所以它全年都在悄悄变大。每年九月花两分钟，就能避免它变成 30 GB。
一次找出全部六个
Bytesweep 会按名称识别每个 Xcode 文件夹，显示它的大小，并把归档标为值得审阅而非可安全清理。你清理的一切都会进入还原点，因此七天内撤销只需一次点击。
相关内容： Docker disk space · 完整的 Mac 清单
问题
删除 DerivedData 安全吗？
安全。它完全是从你的源码派生出来的，名字就是这个意思。唯一的代价是每个受影响项目的下一次构建是完整构建。
删除 DeviceSupport 会影响在手机上调试吗？
不会。下次你连接运行那个 iOS 版本的设备时，Xcode 会重新复制符号。此后的第一次连接会多花几分钟。
我可以删除 Xcode 归档吗？
可以，但先想清楚。归档里存着你已发布构建的 dSYM 文件，没有它们，这些版本的崩溃报告就无法符号化。仍在用户手里的版本请保留；旧的测试版可以放心删除。
为什么 Xcode.app 本身这么大？
大约 15 GB，因为它内置了苹果支持的每个平台的工具链、SDK 和模拟器运行环境。你可以在「Xcode → 设置 → 组件」中移除不用的模拟器运行环境，但应用包本身就是那么大。
Xcode 会自动清理这些吗？
不会。这些文件夹都没有大小上限，也没有过期时间。这正是本页存在的原因。