Silt

usesilt.app · Download for Mac

A fast, live disk-space explorer for macOS. It's a drillable file tree in the spirit of WinDirStat: it fills in while it scans and stays current as files change.

Build and run

scripts/build-app.sh            # build/Silt.app
scripts/build-app.sh --install  # also copy to /Applications and launch
swift test                      # engine tests

Requires macOS 15+ and Xcode 26. You can also launch the binary with a folder to scan it straight away (Silt.app/Contents/MacOS/Silt ~/dev), or drop a folder on the window or the Dock icon.

For a complete picture, give Silt Full Disk Access (System Settings → Privacy & Security). Without it, Silt skips other apps' containers rather than trigger a privacy prompt for each one, and marks them as locked.

Releasing

Releases are cut by GitHub Actions (.github/workflows/release.yml), on GitHub's free hosted runners for public repositories. To release, bump CFBundleShortVersionString in Resources/Info.plist and push to main. A push whose version has no published release yet runs the tests, then scripts/release.sh, which builds a universal (arm64 + x86_64) app signed with Developer ID and the hardened runtime, inside a signed drag-to-install disk image, and notarizes and staples both. It then publishes a GitHub release v<version> with the disk image. A run that fails publishes nothing. Pull requests run the tests (ci.yml).

The workflow signs and notarizes with secrets kept in a release environment that only main can deploy to, set once with scripts/setup-release-secrets.sh path/to/DeveloperID.p12 (the Developer ID Application identity exported from Keychain Access, plus an Apple ID and an app-specific password; each is checked before it's uploaded).

To build a release locally instead:

xcrun notarytool store-credentials silt-notary --apple-id <Apple ID email> --team-id Z4PL6853AL
NOTARY_PROFILE=silt-notary scripts/release.sh

That needs a clean working tree. An App Store Connect API key works too (NOTARY_KEY_P8, NOTARY_KEY_ID, NOTARY_ISSUER_ID), and SILT_RELEASE_IDENTITY picks another Developer ID identity. Without credentials the image is signed but not notarized: Gatekeeper blocks it on other Macs, so don't hand it out. The background comes from swift scripts/make-dmg-background.swift, and the window layout from scripts/dmg/layout.json.

Using it

Show in Finder	⌘R, double-click a file, or the hover button
Focus into a folder / open a file	⌘↓
Enclosing folder	⌘↑
Quick Look	Space
Copy path	⌥⌘C
Mark for Cleanup	M (or the hover button)
Review & clean up	⌘↩
Move to Trash	⌘⌫
Delete immediately	⌥⌘⌫ (asks first)
Files · Largest · Duplicates · Reclaim · Types	⌘1 – ⌘5 (or the toolbar)
Rescan in place	⇧⌘R
Rescan from scratch	⌥⇧⌘R

Other features:

• Cleanup basket. Mark anything with M, from Reclaim ("Mark All Safe"), or from Duplicates ("Mark All Extras"). A bar above the status line keeps a running, deduplicated total, and the capacity meter shows the marked share hatched. The review sheet gives every item a safety verdict (and warns about anything Silt would keep), can pull in everything Safe to clear, and lets you choose between Trash and deleting now. Only Trash is on the Return key. A mark remembers the exact file it was made on: if that file is replaced by another with the same name, the mark is dropped, not carried over. Marks survive a relaunch. Silt never deletes system or home folder locations, or a volume mounted inside the scan.

• Undo and follow-through. "Moved to the Trash" toasts have Undo, which puts everything back. The status bar remembers what's still waiting in the Trash and offers to empty it.

• Where the space is. Click the capacity meter for the volume's ledger:

  • Available: split into what's free right now and what macOS clears on demand.
  • Being deleted: Silt's deletes in progress.
  • In the Trash.
  • Marked for cleanup.
  • Held by local snapshots: space Silt removed that local Time Machine snapshots still keep.

  A file a snapshot holds frees nothing until that snapshot goes. Silt measures each removal against the volume's snapshots before anything goes. Confirmations and results say how much comes back right away (at least) and how much stays held (at most). Silt tracks held space until its last snapshot is gone, and nothing counts as freed until it has been.

• What changed. Silt compares against the last scan (or the moment this one finished) and shows the folders that grew or shrank most: a status-bar chip ("+2.8 GB since yesterday") opens the list, and changed folders carry a "+1.2 GB" tag in the tree.

• Guidance. Rows for known things get a tag (Dependencies, Build output, Cache, Installer…). The inspector explains what the selection is, whether it's safe to remove, the exact reinstall command its lockfile implies, and how long its project has sat untouched.

• Duplicates finds files with identical contents. It compares size, then a sampled hash, then a full SHA-256, and skips dependency and build folders unless you ask. Results stream in, largest first. APFS clones already share their blocks, so they aren't counted as waste. Before anything is marked, every copy is re-checked against the exact file that was compared. Cleanup never removes the last copy: a marked copy goes only while another copy stays, unchanged since the search, and a copy edited since is left alone.

How it's fast

• SiltCore (C) lists directories with getattrlistbulk across a pool of threads. Each listing is one syscall pass plus one short critical section that appends the entries and pushes size deltas up the ancestor chain. So every folder's total is correct-so-far at every instant, and the UI shows it live.
• The pool sizes itself. Past a point, more threads mostly buy the kernel more contention, not more speed. So the pool starts small and grows only while an extra pair of threads makes listing faster without making each item much more expensive. Threads leave after 5 s with nothing to do, so a settled scan holds none. Work Silt does on its own (keeping up with changes, catching up after a relaunch) runs as background work at utility priority, four at a time. On ~/dev that is about 2.5× slower than a full scan, for under one core on average. Each class's priority and limit can change mid-scan: that's the speed setting. Listing never updates access times.
• The tree is flat and chunked: 24 bytes per entry, 48 per folder, and names in a shared arena. About 1.2M entries fit in ~55 MB.
• After the scan, an FSEvents stream re-lists only the folders that changed, and a re-listing updates the folder where it is: files that are still there keep their slot and name, new ones take spare room at the end, and vanished ones are marked removed. A folder only moves when it outgrows that room, and memory no folder uses any more goes back to the system. On a drive with cargo builds running, memory stays flat where it used to grow by ~200 MB a minute.
• Big folders that change constantly (build output, browser caches) are re-listed at a pace that scales with their size: a 60,000-file folder is re-listed at most every 2.4 s, and small folders update immediately. Any folder that changes again right after being listed waits twice as long next time, up to 30 s, and cools off once it's quiet. Whole-tree views (Largest, Types, the inspector's breakdown) skip folders where nothing changed and otherwise refresh at a pace set by what their last pass cost.
• Instant relaunch. A settled scan is saved as a compacted, LZ4-compressed snapshot (about 26 MB for 1.2M items) in ~/Library/Caches/com.jonnyasmar.silt/Snapshots, when the scan settles, at quit, and at most every 30 minutes. Loading streams straight into the tree. Reopening the same location shows it immediately, then FSEvents replays everything that changed since, so only those folders are re-listed. A replay that drops events (on a busy disk, long ones do) can't be trusted, so Silt stops it and checks everything again in the background instead. Removable and network volumes always rescan, and ⇧⌘R forces a fresh scan.
• One copy of everything. A location or folder inside a scan that's already open (Home inside Macintosh HD, a project inside ~/dev) is shown from that scan, instantly, rather than scanned again. If the smaller one was scanned first, it folds into the bigger one when that finishes; marks and open folders carry over. Each view keeps its own place.

Measured on ~/dev (1.3M items) on an M3 Max, with other work loading the machine (load average 24–92). This is the release app, launched hidden, in the same session as the build before the performance round:

	Before	Now
Full scan: CPU time	101 s	29 s
Full scan: wall time	11.3 s	8.9 s
Settled memory	215 MB	172 MB
Settled CPU on a changing disk	1.9 s a minute	0.1 s a minute
Settled CPU on a quiet folder	1.8 % of a core	~0.03 %
Threads when settled	32–35	4–7

For comparison, two back-to-back runs on 2026-10-05 on the same folder (by then 1.1M items, warm cache, heavily loaded machine): Silt's engine took 9.0 and 10.8 s, du -sk 26.8 and 40.8 s.

Sizes, precisely

Sizes are bytes on disk, counted once. Blocks shared by several hard links or APFS clones are split between the files sharing them. Full clones count size ÷ clone count; a partial clone counts its own blocks plus half of what it shares. On a volume full of cloned cargo target folders, Silt reports 1,143 GB against 1,157 GB used according to df (the rest is APFS metadata and snapshots). The inspector shows a clone's full size alongside its share.

For whole volumes, the difference between what the volume says is in use and what the scan found appears as System & hidden space. Expand it (or select it) to see what it's made of: purgeable space (local Time Machine snapshots and caches macOS frees by itself), the other volumes sharing the disk (swap, Preboot, Recovery), and data only macOS can read.

Support

Silt is free and open source. If it got you some space back, you can buy me a coffee.

License

MIT. See LICENSE.