See what is really inside macOS System Data and delete it, item by item, from the menu bar.
System Data
A menu bar app that shows what is really inside macOS "System Data" and lets you delete it, item by item.
Open System Settings > General > Storage on a developer Mac and "System
Data" is often the largest line, with no way to see inside it. Finder puts
everything it cannot attribute to an app, photos or documents in that bucket:
simulator runtimes, Xcode symbol caches, package-manager stores, virtual
machine disks, the unified log, per-app data folders.
This app opens the bucket. It is not a cache cleaner: ~/Library/Caches is
one small line among fifty, and the app never deletes anything you did not
click.
Every release is listed in [CHANGELOG.md](CHANGELOG.md), including the two
that shipped a broken updater and what to do if you are on one of them.
## Install
brew install --cask Jarvis322/tap/sysdata
Or download SysDataMenu-.dmg from the
[latest release](https://github.com/Jarvis322/macos-sysdata/releases/latest),
open it and drag the app onto Applications. A .zip of the same app is
attached to every release for anyone scripting the download.
Releases from 0.3.2 on are signed with a Developer ID and notarized by
Apple, so the app opens without a Gatekeeper prompt. From 0.3.7 the binary
is universal; 0.3.2 to 0.3.6 were Apple Silicon only and will not launch on
an Intel Mac.
Build from source (Xcode 16 or later):
git clone https://github.com/Jarvis322/macos-sysdata.git cd macos-sysdata scripts/build-app.sh open build/SysDataMenu.app
The app has a Launch at login switch in its footer.
## Updates
The app can check GitHub once a day for a newer release and offer to install
it. It is off by default, and it is the only network request the app
makes: with the switch off, nothing leaves the Mac.
Installing replaces the app in place. 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.
## Uninstall
brew uninstall --zap --cask sysdata
--zap is the part that matters: without it the app goes and its files stay.
If it was installed by dragging the disk image, drag the app to the Trash and
remove the four things it leaves behind:
rm -rf ~/Library/Application\ Support/SysDataMenu \
~/Library/Caches/local.sysdata.menu \
~/Library/HTTPStorages/local.sysdata.menu \
~/Library/Preferences/local.sysdata.menu.plistThe first of those is the scan history, which records the path of everything
the app measured and everything you deleted. It never leaves the machine, but
it is the file worth being deliberate about. Remember what changed in the
settings menu deletes it at any time without uninstalling anything.
Two grants outlive the app, because macOS keeps them rather than the app:
entry with the − button.
If Launch at login was on, switch it off before uninstalling, or remove
the entry from System Settings > General > Login Items afterwards.
Nothing else is left. 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.
## What it does
the number Storage settings calls System Data. The window header says how
much of it is safe to free right now. It scans on launch and once a day.
Results appear as each place is measured, with a count in the header, so a
slow first scan on a full disk cannot be mistaken for a stuck one.
Safe regenerates automatically, Review costs you something (a
simulator, a login, a re-download), Manual cannot be removed by the app
and the info button shows the command or settings path.
undone for 30 days. Safe items are deleted outright because they come back
on their own.
way Finder and Mail do it; delete stays visible, because it is the reason
the window is open. Right-click reaches all of them without a pointer.
and the sort control orders by it. Size cannot tell a build folder for
today's work apart from one for a project abandoned two years ago; those
are the same number of bytes and opposite decisions. Simulator runtimes
take their date from simctl, which knows when one was last booted.