vashpan/xcode-dev-cleaner: Xcode Cache Cleanup on macOS

Why DevCleaner Targets Xcode Storage Growth

DevCleaner addresses a storage problem created by Xcode and related Apple development workflows: files generated for debugging, builds, exports, documentation, simulators, and connected devices can remain in a developer's home directory after their immediate purpose has passed. The README specifically points to `~/Developer`, saying that Xcode can store tens of gigabytes there and that cached files and symbols are not necessarily reclaimed over time. That makes the application most relevant to developers working on Macs with limited SSD capacity, especially those who install multiple platform releases or retain many generated artifacts.

The target is not one undifferentiated cache directory. DevCleaner presents separate categories so a user can decide what may be removed. Device support data is selected by default except for the latest version of each system. Archives and Derived Data require more deliberate retention decisions because their contents are not necessarily disposable. Other categories target documentation caches, old simulator and device logs, and documentation downloads left by older Xcode versions.

This is a local cleanup application rather than a source-code build dependency or command-line package. The README points users to the Mac App Store and describes DevCleaner as an application for inspecting auto-generated files and cleaning them when necessary. It may also remind the user to run another scan after some time, although it does not specify the reminder interval or scheduling behavior.

DevCleaner's Cleanup Categories and Retention Rules

Device support is the largest stated target. The README says Xcode downloads symbols when a new iOS, visionOS, watchOS, or tvOS device version is connected, and it estimates roughly 2 to 5 GB per version. Even a small device update can bring new symbols, so older versions can accumulate. DevCleaner preserves the latest version for each system by default and allows older entries to be considered for cleanup. The README does not expose a configurable retention policy beyond that default behavior.

Archives are different. They contain a build, debug symbols, and other information created for distribution or export. Historical archives can remain useful for crash symbolication, particularly for apps that are still deployed to users. The application therefore cannot treat every archive as disposable. Its value here is inspection and selective deletion of older or no-longer-distributed builds, not an automatic purge.

Derived Data contains autocompletion data, logs, debug builds, intermediate products, and other generated material. The README describes it as regenerable, which makes it a stronger cleanup candidate than archives, although deletion may force Xcode to recreate data and can make some older project data disappear entirely. The documentation cache addresses web documentation that older Xcode releases did not clean sufficiently. Old simulator and device logs are treated as historical diagnostic data for which only recent copies may matter. Old documentation downloads came from an offline feature in older Xcode versions and may occupy many gigabytes even when current Xcode relies on online documentation.

That category split is the central design decision. DevCleaner avoids presenting every generated file as equivalent cache, but the README does not document dry-run output, exclusion files, logs of deletions, selective restore, or rollback.

Undocumented Xcode Folders Create the Main Risk

The clearest limitation appears in the project's own warning: DevCleaner relies on internal folder structures and undocumented Xcode features. It may stop working with a newer Xcode version. This is not a minor compatibility footnote. The application is not working through a documented public Xcode cleanup API, so an Apple change can alter where it searches, how entries are named, or which data can safely be classified.

The README says the author tried to make the application safe and recommends making a backup before use. That advice matters most for archives and any other files that cannot be regenerated easily. A backup does not guarantee that DevCleaner will identify every new directory correctly, but it gives the user a way to recover an archive or local project-associated data if a selected item turns out to matter.

Compatibility is also version-specific. The README states that the application is currently tested with macOS 14.x and Xcode 15.x and says earlier Xcode versions should be supported. It does not state support for later Xcode or macOS releases. DevCleaner is therefore a poor fit for an unattended cleanup policy across a fleet of Macs with mixed toolchains. Users need to inspect each app's interface and retain control over deletion rather than placing it in an automated storage-management policy.

The repository contains `DevCleaner.xcodeproj/`, so its Swift source can be modified under GPL-3.0. The README permits modification, download, redistribution, and use, but notes that only the copyright holder can submit the application to the Mac App Store. GPL-3.0 obligations apply to distribution and modification, and this article does not provide legal advice about a particular distribution method.

Installing DevCleaner and Performing a First Inspection

DevCleaner does not document a Homebrew, Swift Package Manager, or command-line installation route. Its documented distribution point is the Mac App Store. A first-time user should obtain DevCleaner from that listing, install the application on a Mac with Xcode-generated data, and make a backup before deleting anything. The README does not give the App Store purchase price, menu sequence for the first scan, or any command-line flags, so none can be supplied as a verified tutorial.

For the first use, begin with Device Support because it is selected by default while preserving the newest version for each Apple system. Check the reported paths and sizes before confirming deletion. Then inspect Archives independently, because the README identifies them as useful for crash symbolication. Derived Data is described as regenerable, but removing an old project's directory can remove more than a small cache. Review old logs and documentation downloads only after checking whether any offline reference or diagnostic record is still needed.

The expected result is reclaimed disk space with some Xcode information rebuilt on demand. The documentation does not promise an exact reclaimed amount because cache composition differs by machine. It also does not document an undo action. After a cleanup, retain the backup until normal project builds, archive symbolication, simulator use, and documentation access have been checked.

DevCleaner Compared with Manual Xcode Directory Cleanup

The practical alternative is manual inspection and deletion of Xcode-generated directories under `~/Developer`. Both approaches can reclaim disk space, and both become harder to interpret when folder contents accumulate over years. The difference is control and discoverability. DevCleaner groups device support, archives, Derived Data, documentation, and logs into named cleanup decisions and keeps the latest device support version by default.

Manual cleanup offers more direct control over paths, but it requires the user to understand which directories belong to which Xcode function and which files can be regenerated. Deleting the wrong project-specific Derived Data can remove older work rather than merely clear a reusable cache. DevCleaner's category view reduces that discovery burden, although it does not eliminate the retention consequences.

Another alternative is simply relying on Xcode's own storage management. DevCleaner's README specifically identifies documentation caches and older logs as data that may not be cleaned by Xcode, so relying only on the IDE would not cover the full problem described by the project. DevCleaner is most useful when manual inspection is unattractive and Xcode's built-in behavior leaves accumulated files behind. It is least useful when every deletion must be justified through documented Xcode APIs, because DevCleaner explicitly depends on internal structures.

Maintenance, Releases, and Upgrade Boundaries

The repository is not archived. Its last push was on 2026-05-18. Release history includes version 2.8.0 dated 2025-11-11, version 2.7.1 dated 2025-04-26, and version 2.7.0 dated 2024-10-13. Those dates show that updates have occurred across recent years, but the README does not provide release notes, migration notes, or a compatibility matrix.

Because DevCleaner parses undocumented Xcode storage, an Xcode upgrade can be as important to this application as a DevCleaner upgrade. The stated macOS 14.x and Xcode 15.x test target should be checked before adopting the app for a newer environment. The README also does not document automatic application updates, App Store distribution details, or whether older releases support a particular Xcode layout.

The GPL-3.0 license permits reuse and modification, but the Mac App Store submission restriction is specific and should be accounted for by anyone considering redistribution. A source build would also require working through `DevCleaner.xcodeproj/`, yet the README does not document Xcode project settings, signing requirements, entitlements, or a tested build command. For most users, the Mac App Store remains the only installation route documented by the project.

Editorial conclusion

Adopt DevCleaner if disk pressure from Xcode-generated files is affecting a Mac and you can accept backup, regeneration, and compatibility costs. Do not adopt it if you need a formally supported cleanup mechanism or cannot tolerate breakage after an Xcode update. Before deleting anything, verify the listed macOS and Xcode versions against the app's stated support and back up data that the interface marks as not safely regenerable.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. vashpan/xcode-dev-cleaner on GitHub