# System Data Unpacked: a menu bar app that shows what macOS System Data actually contains

> System Data Unpacked (repository Jarvis322/macos-sysdata) turns the opaque System Data line in Storage settings into a list of named items with real sizes, a Safe/Review/Manual badge, and the exact command it will run before it runs it. It is for Mac users with a full disk, and it is not a general cache cleaner.

**Jarvis322/macos-sysdata** — 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.

- Repository: https://github.com/Jarvis322/macos-sysdata
- Website: https://macos-sysdata.yigitech.dev
- Stars: 842 · Forks: 37
- Language: Swift
- License: NOASSERTION
- Published: 2026-09-13 · Updated: 2026-09-13 · Language: en
- Canonical page: https://hysenlabs.com/projects/jarvis322-macos-sysdata

## The bucket macOS refuses to itemise

Open System Settings, then General, then Storage, and System Data is often the largest line on a developer Mac. The README explains why: Finder puts everything it cannot attribute to an app, photos or documents into that bucket. Simulator runtimes, Xcode symbol caches, package-manager stores, virtual machine disks, the unified log and per-app data folders all land there. The number is real but the contents are unnamed, so the only decision available is to ignore it or to start deleting folders by hand.

System Data Unpacked is a Mac app that runs in a window or in the menu bar and lists what the bucket holds. The README is explicit that it is not a cache cleaner: `~/Library/Caches` is described as one small line among fifty. The audience is narrow and identifiable. If your disk is full and the Storage pane blames System Data, this app is aimed at you. If you want a tool that sweeps caches on a schedule, it is not.

## Sizes, badges, and the three-tier delete model

Every item is measured on disk and carries a badge. Safe means the item regenerates automatically. Review means removing it costs you something: a simulator, a login, a re-download. Manual means the app cannot remove it at all, and the info button shows the command or the settings path instead. That third tier is the honest part of the design. Some of what fills System Data is not the app's to delete, and rather than hide that, it surfaces a manual route.

The delete behaviour differs by badge. Review items go to the Trash, so a wrong click can be undone for 30 days. Safe items are deleted outright, on the argument that they come back on their own. The menu bar icon shows the total the scan found, and the window header says how much of it is safe to free right now. Scans run on launch and once a day, and results appear as each place is measured, with a count in the header, so a slow first scan on a full disk is not mistaken for a stuck one.

One detail stands out as more useful than the size column: idle time. Rows past a fortnight say how long they have sat untouched, and the sort control orders by it. The README makes the case directly. A build folder for today's work and one for a project abandoned two years ago are the same number of bytes and opposite decisions. Simulator runtimes take their date from `simctl`, which knows when one was last booted.

## Installing with Homebrew and reading the first scan

The documented install is a Homebrew cask. The README notes the cask kept its old name after the app was renamed from SysDataMenu at 1.0.4, so the command is not what you would guess from the app title.

```bash
brew install --cask Jarvis322/tap/sysdata
```

If the app is already in Applications from the disk image, that command stops with "It seems there is already an App". The README gives the fix, which hands the existing copy to Homebrew rather than reinstalling it.

```bash
brew install --cask --adopt Jarvis322/tap/sysdata
```

A disk image named `SysDataMenu-<version>.dmg` is attached to the latest release if you prefer dragging the app onto Applications, and a `.zip` of the same app is attached for anyone scripting the download. Releases from 0.3.2 on are signed with a Developer ID and notarized, so the app opens without a Gatekeeper prompt. Building from source needs Xcode 16 or later:

```bash
git clone https://github.com/Jarvis322/macos-sysdata.git
cd macos-sysdata
scripts/build-app.sh
open "build/System Data Unpacked.app"
```

The first launch runs a scan. Expect it to fill in gradually rather than all at once, which the header count is there to make legible. Two settings matter before you delete anything. Launch at login is a switch in the app footer. The update check is off by default; turning it on is the only network request the app makes, and with it off nothing leaves the Mac.

## What changed: the feature that justifies keeping a history file

Each scan and each deletion is written to a local file. That lets the list show growth beside each size, and a history view answer three questions a single scan cannot: what came back, what grew most, and what you deleted. The README's own example is the sharpest argument for the feature. A cache cleared on Monday that is 12 GB again by Friday tells you something about the cache, not about the disk.

The file is also the privacy trade-off. It records the path of everything the app measured and everything you deleted. It never leaves the machine, but it is a local record of your filesystem, and the README says so rather than burying it. Remember what changed in the settings menu deletes it at any time without uninstalling anything. Switching the feature off deletes the file too. If you share a Mac or image the disk, that is the setting to think about first.

## No privileged helper, and the cost of that choice

The app installs no privileged helper, no launch daemon and no kernel extension. Every root action runs as a one-off `osascript` prompt, which is why it asks each time and shows you the command first. That is a real security property: there is no persistent component running as root, and nothing to audit beyond the app bundle.

The cost is friction. You will approve prompts repeatedly, and the app is designed so that you cannot approve something you have not seen. If you want a cleaner that runs unattended, this architecture rules it out by construction. The README does not document a way to pre-authorise a set of deletions or to run the scan headlessly from the `sysdata` binary listed at the repository root, so treat the interactive prompt as the only supported path.

Two grants outlive the app because macOS keeps them rather than the app: Full Disk Access under Privacy & Security, and Notifications if the low-space warning was enabled. The README also notes that if Launch at login was on, it should be switched off before uninstalling, or the entry removed from Login Items afterwards.

## Where the updater has already failed, and what that says

The README points at CHANGELOG.md and says it lists every release, including the two that shipped a broken updater and what to do if you are on one of them. An updater that has broken twice in a project this size is worth reading about before you enable the daily check. The install path itself is guarded: 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 with a message and the installed app is left alone.

The honest reading is that the update mechanism is the least proven part of the app, and the project says so in its own changelog rather than in a footnote. If you install through Homebrew, upgrading through `brew` sidesteps the in-app updater entirely, and the README does not document rollback beyond the changelog's recovery notes.

## Licence and uninstall: what stays behind

The repository's licence file does not resolve to a standard identifier, and the README badge labels the app proprietary. That combination matters more than usual here. You are running a signed, notarized binary that performs deletions, and you cannot audit the deletion logic the way you could with an open source tool. The repository does publish sources, a `Package.swift`, tests and a build script, but the badge and the missing standard licence identifier mean the terms are not something a reader can infer. Read LICENSE before redistributing anything. This is a description of what the files say, not legal advice.

Uninstall has one trap. The Homebrew command is:

```bash
brew uninstall --zap --cask sysdata
```

Without `--zap`, the app goes and its files stay. If it was installed by dragging the disk image, the README lists four paths to remove by hand, including `~/Library/Application Support/SysDataMenu`, the scan history. Note the bundle identifier and the command-line binary kept their old names through the 1.0.4 rename, so Full Disk Access grants, settings and any scripts carry over without reinstalling. That continuity is convenient and also means an old grant can sit in Privacy & Security long after you stop using the app.

## How it compares with a cache cleaner like CleanMyMac

The obvious alternative is a general Mac cleaner such as CleanMyMac, and the difference is not feature count. A cleaner of that kind decides what is disposable and acts on your behalf, usually across caches, logs and leftovers in one pass. System Data Unpacked refuses that role in two ways. It never deletes anything you did not click, and a whole tier of items, the Manual badge, it will not delete at all. Where a cleaner optimises for a single button, this app optimises for a decision per row.

The second difference is what it measures. A cache cleaner's target is caches. This app's target is the System Data bucket, which the README describes as containing simulator runtimes, Xcode symbol caches, package-manager stores, virtual machine disks, the unified log and per-app data folders. Those are largely developer artefacts, not caches, and several of them are large. If you are not a developer, a substantial part of what this app lists will not exist on your Mac, and the app will have less to show you than the Storage pane implies.

## Conclusion

Adopt it if you are on macOS 14 or later and the System Data line in Storage settings is large and unexplained, especially on a developer Mac with simulator runtimes and Xcode caches. Do not adopt it if you want a one-click cleaner: it never deletes anything you did not click, and Manual rows are not removable by the app at all. Before installing, read CHANGELOG.md for the two releases that shipped a broken updater and the recovery instructions, and check your macOS version, because 0.3.2 to 0.3.6 were Apple Silicon only.

## FAQ

### Why is macOS System Data taking up so much space?

The README explains that Finder puts everything it cannot attribute to an app, photos or documents into that bucket, including simulator runtimes, Xcode symbol caches, package-manager stores, virtual machine disks, the unified log and per-app data folders. System Data Unpacked lists those items individually with a size measured on disk.

### How to see what system data is on a Mac?

Install the app and let the first scan run; results appear as each place is measured, with a count in the header. Each row carries a real on-disk size and a Safe, Review or Manual badge, and the info button on Manual rows shows the command or settings path.

### How can I clear system data on my Mac in 2026?

The app deletes item by item rather than in one pass. Safe items are deleted outright because they regenerate, Review items go to the Trash so a wrong click can be undone for 30 days, and Manual items cannot be removed by the app. Every root action runs as a one-off osascript prompt that shows the command first.

## Sources

- [Issues](https://github.com/Jarvis322/macos-sysdata/issues)
- [Jarvis322/macos-sysdata on GitHub](https://github.com/Jarvis322/macos-sysdata)
- [Project website](https://macos-sysdata.yigitech.dev)
- [README](https://github.com/Jarvis322/macos-sysdata/blob/main/README.md)
- [Releases](https://github.com/Jarvis322/macos-sysdata/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jarvis322-macos-sysdata