Purge: a trash-by-default macOS cleaner that only touches what it can name
Free up your Mac, safely. Clears the cache and junk it piles up on its own. Open source, and everything goes to the Trash, so nothing is ever lost.
At a glance
- What is it?
- Purge is an MIT-licensed SwiftUI app that scans ~/Library/Caches, developer tool caches, and large personal files on macOS, labels each item Safe to Clean or Check First, and moves everything to the Trash instead of deleting it. The design bet is that a cleaner should only show what it recognizes.
- Who is it for?
- Purge fits Mac users who want cache cleanup without a permanent-delete button, and developers whose Derived Data, node_modules, and simulator runtimes have quietly eaten the disk. It is a poor fit if you need scripted, headless cleanup across a fleet, or if you want a tool that reasons about folders it has never seen.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The junk problem Purge is aimed at
macOS accumulates data that no one deliberately created. Application caches in ~/Library/Caches, sandbox container caches, crash reports, application logs, macOS installers, and font caches all grow on their own. The README frames the problem in exactly those terms: cache and junk the Mac collects without being asked. The people who feel this most are not casual users. They are developers whose Xcode Derived Data, Archives, and DeviceSupport folders expand with every build, whose node_modules directories multiply per project, and whose unused iOS simulator runtimes sit on disk long after the app they belonged to was deleted. Purge targets both groups with one interface, splitting the work into App Caches, Dev Tools, and Large Files.
The distinguishing choice is what Purge refuses to do. The README states that unidentified folders are left out of the list entirely, and that Purge only shows what it knows about. That is a narrower promise than most cleaners make. A tool that scans everything and guesses is more likely to reclaim space and more likely to break something. Purge picks the opposite trade: a curated set of recognized locations, each with a plain-English explanation and a safety label, and silence about everything else.
How the scan is organized and what the safety labels mean
Purge assigns every recognized item one of two labels. Safe to Clean means a known cache or rebuildable artifact. Check First means it may be safe but could cause inconvenience. The UI lets you filter with All, Safe to Clean, or Check First, bound to Command-1 through Command-3, and sort by size, date modified, or name. Results stream in as they are found rather than appearing after a full scan completes, which matters when a Homebrew or Xcode scan takes a while.
The one-click Clean button in the sidebar names the exact amount it will move, and the README says it only touches Safe to Clean items, with git and lockfile checks. Those checks are the interesting part and the README does not spell out their mechanics. What can be said from the material is that Purge will not blindly remove a node_modules folder inside a repository with uncommitted work, or a lockfile it considers load-bearing. The exact conditions are not documented in the README, so treat the checks as a guardrail whose boundaries you should confirm yourself before relying on them.
Duplicate cache locations for the same app are merged into a single row, so you are not asked to make the same decision twice. Large media caches from Premiere Pro and After Effects get their own treatment, as do system junk categories like application logs, crash reports, macOS installers, and font cache.
Dev Tools: three sections, one view
The Dev Tools screen splits into global dev tool caches, iOS Simulators, and developer projects. The global list covers Xcode (Derived Data, Archives, DeviceSupport), Homebrew, npm, pnpm, Yarn, CocoaPods, Gradle, Flutter, Docker Desktop, VS Code, Cursor, JetBrains, Cargo, and Terraform, among others named in the README. The simulator section groups unused simulator runtimes and skips booted ones, which is the correct default: deleting a runtime that a running simulator depends on is a bad afternoon.
The developer projects section is where the configuration lives. In Settings, Developer Projects, you set Consider stale after to a value between 1 month and 2 years, or Show all. That threshold decides which project folders appear for scanning. The artifacts it looks for include node_modules, Python virtual environments, Rust target directories, Flutter build output, Xcode Pods, and Android .gradle. The stale threshold is doing real work here. Set it to Show all and every project on the machine becomes a candidate, which is the wrong setting if you keep long-lived repositories you rebuild rarely. Set it too short and projects you touched last month disappear from the list, which is the wrong setting if your goal is to reclaim space from active work.
One structural decision worth noting: Large Files deliberately skips project folders like node_modules, Pods, DerivedData, and build output. The README explains why. Deleting a single file out of a dependency tree only breaks the install, so those belong in Dev Tools, which removes them a folder at a time. That is a coherent boundary between the two features, and it is the kind of reasoning most cleaners skip.
Large Files, duplicates, and local AI models
Large Files scans Documents, Desktop, Downloads, Movies, Music, and Pictures. It skips managed libraries such as Photos, iMovie, and Music, hidden folders, and the project folders described above. Filters cover size from 5 MB to 1 GB and last used from any time up to over 1 year ago. Category chips cover videos, audio, images, PDFs, archives, documents, AI models, and other files. Search matches the file name, the folder it sits in, and its source label, so you can filter by where a file came from as well as what it is called. Each row offers Quick Look preview and Reveal in Finder.
The duplicates feature is a byte-for-byte scan that groups identical copies and reports how much you would reclaim by keeping one. Purge does not pick which copy to keep. The README states that explicitly, and it is the right call: a cleaner that guesses which duplicate matters is a cleaner that deletes the wrong one. A Duplicates chip gathers them into one place so you can decide.
The AI models handling is the most technically specific thing in the README. Models downloaded with Ollama or LM Studio appear under the AI Models category, one row per model, named the way you installed it. Purge understands Ollama's content-addressed storage, so a model's size counts only the bytes that would actually be reclaimed rather than blobs shared with another model. That detail matters because Ollama stores layers by hash and shares them across models. A naive size calculation would double-count shared blobs and overstate the space you get back. Whether the implementation matches the description is something you would have to verify against your own Ollama store, but the stated behavior is the correct one.
Building and running it from source
The repository is Swift with SwiftUI, licensed MIT, default branch main, and the README links a build workflow at .github/workflows/build.yml. The README offers a Download link to the latest release, an install guide section, and a build from source section. The cleaned README text available here does not include the literal commands for either path, so the exact xcodebuild invocation or Swift Package Manager command is not something I can give you without guessing. Check the Installation and Build from source sections in the repository README for those.
What the README does document precisely is the settings surface, and that is where configuration actually matters for day-to-day use. Appearance takes Light, Dark, or System. Cleaning Schedule has Run automatic cleaning plus a How often choice of weekly, monthly, or every 3 months, along with the next-clean date and a summary of the last clean. Developer Projects holds the Consider stale after threshold. Excluded from scans holds folders you have told Purge to leave alone, each shown with its current size, and you add one by right-clicking any scan result and choosing Exclude from scans. The README notes that excluding only ever narrows what Purge looks at, which is a useful property: the exclusion list cannot expand the scan surface.
Scheduled cleaning deserves a precise reading. The README says Purge sends a local reminder and cleans safe items when you open the app. It is not a background daemon that runs while the app is closed. If you never open Purge, the schedule does not fire. That is a meaningful limitation for anyone expecting a launchd-style background job.
Where Purge is the wrong tool
The unidentified-folder policy cuts both ways. If a large directory is not in Purge's recognized set, it will not appear, and you will get no signal that it exists. A cleaner built on a fixed catalog will always lag behind new applications and new cache locations. The README does not describe a mechanism for adding custom scan targets beyond the Excluded from scans list, which only subtracts. If your disk is full because of something Purge has never heard of, Purge will not help you find it.
The second limitation is the scheduling model already described. Automatic cleaning depends on you launching the app. For a single Mac that is fine. For a build machine or a shared workstation where nobody opens a GUI, it does not apply.
The third is the absence of any scripted interface. The README describes a SwiftUI app with a sidebar, menu bar commands, and settings panes. There is no mention of a CLI, a configuration file, or a headless mode. If you manage many Macs and want cleanup driven by a script or a configuration management tool, Purge is the wrong shape. You would be looking at command-line tools that expose their scan and delete operations as subcommands.
Finally, the trash-by-default behavior is a safety feature with a cost. Nothing is permanently deleted, which means the space is not actually reclaimed until the Trash is emptied. On a disk that is genuinely full, moving 40 GB to the Trash may not free the space you need until you empty it, and emptying the Trash is outside Purge's stated scope.
How this differs from a general-purpose cleaner
The obvious comparison is a tool like Mole, which is a command-line macOS cleaner distributed as a shell script. The difference in approach is structural rather than cosmetic. Mole operates from a terminal, presents results as text, and is designed to be run in a shell session, which makes it scriptable and easy to invoke over SSH. Purge is a GUI application with a catalog of recognized locations, per-item safety labels, friendly app names with brand icons, Quick Look previews, and a Trash-by-default deletion path. Mole gives you a prompt and a list. Purge gives you a reviewed decision per row.
That difference determines the audience. If you want to run a cleanup from a terminal on a remote machine, Mole's model fits and Purge's does not. If you want a visual confirmation of what is about to move, with a named byte count on the button and a per-item explanation, Purge's model is the one that provides it. Neither is strictly better. They trade automation for review.
A second comparison point is the built-in macOS Storage Management panel in System Settings. It offers recommendations and a file browser but does not break out Xcode Derived Data, Homebrew caches, or simulator runtimes as separate, labeled categories. Purge's developer-facing catalog is the part that panel does not attempt.
Maintenance, history, and licence
Purge ships frequently. The releases listed run from v1.3.2 in early August 2026 through v1.3.3 two weeks later to v1.4.0 at the end of that month, and the repository shows a push on 2026-08-31. The project is not archived. That cadence suggests active maintenance, though release frequency alone says nothing about whether a given bug you hit is fixed.
Cleaning History records every automatic and manual clean with the space freed and the item count, and the README says you can open an entry to see what was cleaned. That is the audit trail to check after your first run, because it tells you what Purge actually moved rather than what it promised to move. It is also the fastest way to discover that a scan category you expected to be populated was empty.
The licence is MIT. That permits commercial use, modification, and redistribution provided the copyright notice and permission notice are included. It does not include a warranty, and it does not include a patent grant. That is a general description of the MIT terms, not legal advice, and if you plan to redistribute Purge inside a product you should read the LICENSE file in the repository rather than this summary.
The upgrade cost is low by construction. There is no server component, no account, and no configuration format to migrate. Settings live in the app. The main thing to re-verify after a version bump is whether the developer project scan list or the safety labels changed, since those determine what the one-click Clean button will touch.
Editorial conclusion
Purge fits Mac users who want cache cleanup without a permanent-delete button, and developers whose Derived Data, node_modules, and simulator runtimes have quietly eaten the disk. It is a poor fit if you need scripted, headless cleanup across a fleet, or if you want a tool that reasons about folders it has never seen. Before adopting it, check the Cleaning History entry after your first run, confirm the Excluded from scans list covers any path you care about, and verify that the folders you expect to reclaim space from actually appear as rows rather than being silently left out.
Community notes