macos-sysdata: an item-by-item view of macOS System Data
See what is really inside macOS System Data and delete it item by item. A free menu bar app that explains every category and shows each command before it runs.
At a glance
- What is it?
- System Data Unpacked measures what Finder lumps into System Data and lets you delete it row by row, showing each command before it runs. The README also documents the parts that make adoption awkward: a proprietary licence, a rename that left old bundle identifiers behind, and a scan history file worth thinking about.
- Who is it for?
- Adopt it if you are a developer on macOS 14 or later whose Storage settings show a large System Data figure and who wants to see the individual paths before deleting anything; skip it if you need a scriptable, redistributable cleaner, since the app is proprietary and its deletion model is click-by-click.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- 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 bucket macOS will not itemise
On a developer Mac, System Settings > General > Storage often shows System Data as the largest line, and the README's point is that Finder puts everything it cannot attribute to an app, photos or documents into that one bucket: simulator runtimes, Xcode symbol caches, package-manager stores, virtual machine disks, the unified log, per-app data folders. The app is aimed at the person who owns that machine and wants to know which of those categories is actually eating the disk. The README is explicit that this is not a cache cleaner, noting that ~/Library/Caches is one small line among fifty and that the app never deletes anything you did not click. That distinction matters if you are comparing it with the one-button cleaners that sweep known cache paths. The intended user is a developer or power user on macOS 14 or later, not someone who wants an unattended reclaim job.
A scan, a size per row, and three deletion classes
The mechanism described in the README is a scan that measures each known location on disk and reports results incrementally, with a count in the header so a slow first scan on a full disk is not mistaken for a stuck one. Each item carries a measured size plus a badge. Safe means the item regenerates automatically and is deleted outright. Review means removing it costs you something (a simulator, a login, a re-download) and the item goes to the Trash so a wrong click can be undone for 30 days. Manual means the app cannot remove it at all, and the info button shows the command or settings path instead. The menu bar icon shows the total the scan found, which the README says is the size Storage settings labels System Data, and the window header states how much of that is safe to free right now. Scans run on launch and once a day. Simulator runtimes take their last-used date from simctl, which is a sensible choice: file modification time would not tell you when a runtime was last booted.
Idle time and the change log are the interesting parts
Two features go beyond listing sizes. Rows past a fortnight report how long they have sat untouched, and the sort control can order by that, which addresses a real failure of size-based cleaning: a build folder from today's work and one from an abandoned project are the same number of bytes and opposite decisions. The second is the scan history. Each scan and deletion is written to a local file, so the list can show growth beside each size and a history view can answer what came back, what grew most, and what you deleted. The README's example is a cache cleared on Monday that is 12 GB again by Friday. That is the one claim here that a single scan structurally cannot make, and it is the reason to keep the history on. It is also the file the README flags as worth being deliberate about, since it records the path of everything the app measured and everything you deleted. It stays on the machine, but it is a record of your disk contents in a plain location.
Installing, adopting, and removing it cleanly
The Homebrew path is brew install --cask Jarvis322/tap/sysdata, or you can download SysDataMenu-<version>.dmg from the latest release and drag the app to Applications. The README documents a specific failure: if the app is already in Applications from the disk image, brew install stops with "It seems there is already an App", and the fix is brew install --cask --adopt Jarvis322/tap/sysdata. Releases from 0.3.2 on are signed with a Developer ID and notarized, so no Gatekeeper prompt; the binary became universal at 0.3.7, and 0.3.2 to 0.3.6 were Apple Silicon only. Building from source needs Xcode 16 or later and runs scripts/build-app.sh, then opens build/System Data Unpacked.app. Uninstall is brew uninstall --zap --cask sysdata, where the README stresses that --zap is the part that matters. If you dragged the image, the app leaves four paths, including ~/Library/Application Support/SysDataMenu (the scan history), ~/Library/Caches/local.sysdata.menu, ~/Library/HTTPStorages/local.sysdata.menu and ~/Library/Preferences/local.sysdata.menu.plist. Full Disk Access and, if enabled, Notifications survive the app because macOS keeps those grants; Launch at login should be switched off before uninstalling.
Root actions are one-off osascript prompts, not a helper
The design choice worth understanding is how privileged work happens. The README states the app installs no privileged helper, no launch daemon and no kernel extension, and that every root action runs as a one-off osascript prompt. That is why it asks each time and shows you the command first. This is a genuine trade-off with two sides. On the security side, there is no persistent root component to audit or to keep patched, and nothing runs elevated without a fresh prompt. On the ergonomics side, cleaning many Manual or Review items that need elevation means repeated prompts rather than one authorisation. If your workflow is bulk deletion of system-level paths, this architecture is friction by design. If your concern is what software is running as root on your machine, the absence of a helper is the reason to prefer this over cleaners that install one. The README does not offer a way to batch the prompts.
The updater, the network boundary, and the rename debt
Update checking is off by default and, per the README, is the only network request the app makes: with the switch off, nothing leaves the Mac. When enabled, it checks GitHub once a day. Installing an update replaces the app in place, and before anything is moved the download must have come from github.com over HTTPS, pass the same Gatekeeper assessment a fresh download gets, and be signed by the same team as the copy asking for the update; anything else is discarded and the installed app is left alone. The README also says CHANGELOG.md lists every release including the two that shipped a broken updater and what to do if you are on one of them, which is unusually candid and worth reading before you enable the feature. The rename adds a second kind of debt: up to 1.0.4 the app was called SysDataMenu, and the bundle identifier, Homebrew cask and command-line binary kept their names. That is why the uninstall paths above still say SysDataMenu and local.sysdata.menu, and why Full Disk Access, settings and scripts carry over without reinstalling. It also means the project name and the on-disk names will not match when you go looking.
Licence, maintenance, and what is left unstated
The licence is proprietary, and the README's badge says so plainly, while the repository metadata reports the licence as NOASSERTION. Either way this is not an open source project. For an individual installing a disk utility on a personal Mac that may be acceptable. For a team that needs to redistribute the binary, audit the source, or vendor a patched build, it is a blocker, and the source repository being public does not change the licence terms. Maintenance looks current: the last push was on 2026-09-13, with v1.2.1 released on 2026-09-12, v1.2.0 earlier the same day and v1.1.0 on 2026-09-11, and the repository is not archived. The upgrade cost is low if you use Homebrew, since the cask handles replacement, but the app is not free of state: the scan history in ~/Library/Application Support/SysDataMenu grows as you use it, and the README notes that "Remember what changed" in the settings menu deletes it without uninstalling. What the README does not document is rollback. There is no described way to revert to a previous version after an in-place update, and no documented migration path if a future update changes the history file format. Verify that before you rely on the history view for long-term records.
Editorial conclusion
Adopt it if you are a developer on macOS 14 or later whose Storage settings show a large System Data figure and who wants to see the individual paths before deleting anything; skip it if you need a scriptable, redistributable cleaner, since the app is proprietary and its deletion model is click-by-click. Before installing, read CHANGELOG.md for the two broken-updater releases, confirm you are on 1.2.1, and check whether a copy already sits in Applications so you can use --adopt rather than fight the cask.
Community notes