Everything on Windows makes a simple promise: type part of a filename and see the result before you finish the word. As of writing, there is no official Everything for Mac. macEverything delivers the same workflow on macOS with a different implementation. It builds its own filename index, stores that index locally, and filters it as you type.
Why Everything isn't on macOS
Everything is a Windows application, and its speed comes from facilities that Windows exposes. It reads the NTFS master file table and the USN change journal, which together describe every file on a volume and every change made to it. A search can therefore be answered from a compact database instead of walking the directory tree.
macOS does not offer third-party apps an equivalent public interface. Its default APFS file system has no USN-style journal for applications to consume, and Spotlight's index is system-managed: third parties cannot read or control the underlying database directly. mdfind -name and NSMetadataQuery can query filenames, but their results depend on Spotlight's importers and exclusion rules; when results go missing, these troubleshooting steps cover the common causes.
As of writing, there is no official macOS version of Everything, and macEverything is not a port; it is an independent implementation of the same idea. Any Mac app that wants Everything-style behavior has to assemble its own inventory and keep it current with file-system events. That is the gap macEverything fills.
How macEverything fills the gap
On first launch, macEverything scans two roots: your home folder and /Applications. Three paths are excluded by default: ~/Library, node_modules, and .git. Library holds caches, preferences, and application support data that would flood results with implementation detail, while node_modules and .git are project internals whose file counts can dwarf the documents you actually search for. Exclusions can be adjusted from the command line.
The scan writes a single index file under ~/Library/Application Support/macEverything/. Nothing is uploaded, and searches do not need a network connection. After the initial scan, macEverything listens to FSEvents and updates only the affected parts of the index, so renaming or saving a file does not trigger a full rescan.
The menu bar app and the bundled macEverything CLI read the same index. The CLI lives inside the app bundle at Contents/MacOS/macEverything and is on your PATH only if you installed or symlinked it. A query from Terminal and a query in the floating bar return the same results, which matters when you move between interactive searching and scripts; the Mac file search guide covers more workflows:
macEverything query "invoice"
macEverything statusEverything vs macEverything vs Spotlight
All three tools find files by name, but they answer the question in different ways. The table compares the parts that affect day-to-day use.
| Capability | Everything | macEverything | Spotlight |
|---|---|---|---|
| Index scope | All local NTFS or ReFS volumes by default, plus folders you add | Home folder and /Applications | System-defined; depends on Spotlight settings |
| Live updates | USN change journal | FSEvents; changes searchable within 0.3s | Updates with the system index |
| Index location | Local | Local disk | System Spotlight index |
| Terminal command | es.exe (separate download) | macEverything (bundled) | mdfind (built-in) |
| System index required | No | No | Yes |
Three limits are worth stating plainly. The current version indexes only your home folder and /Applications; external and network drives are not supported. Matching is filename-based and accepts wildcards, path, case, and whole-word filters, but not regular expressions. The interface keeps roughly 136 MB of memory resident, which is the baseline cost of the current UI stack. These are trade-offs of this release, not hidden behavior. External drives in particular are a candidate for a future version.
Measured performance
We tested on an Apple M5 with an index of about 1.28 million entries. A first scan of 1 million files completed in 1.0–1.6 seconds. Query latency at P99 was 2.9–3.6 milliseconds, fast enough that results replace each other while you type. Incremental changes became searchable within 0.3 seconds.
These numbers come from a fixed test set. Your disk, file count, and exclusion list will change them. The index itself is compact: roughly 63 MB per million files, and cold starts load it directly rather than rebuilding. P99 means that 99 percent of queries finished within that time, which is a more useful signal than an average when you are watching results update on every keystroke.
Install and shortcuts
Download the 6.9 MB DMG from this site, open it, and drag macEverything into Applications. The first launch builds the index in the background; results appear as scanning progresses. The app requires macOS 13 or later and Apple silicon.
Press ⌥Space to open the floating search bar. Type any part of a filename and results update as you type; use ↑ and ↓ and Return to open the selection, or ⌥Return to continue in the full results window. Press ⌥⇧F to open that window directly, where you can sort by size or modification date, select multiple rows, press Space for Quick Look, and use the right-click menu to copy the file, path, or file name.
Full Disk Access is optional. Without it, the results window status bar shows a gap count; open it to see the folders rather than having them silently omitted. After granting access, restart the engine (macEverything stop && macEverything start) and the index can add those locations. The CLI must be installed and on your PATH, or use the bundled Contents/MacOS/macEverything.
The index lives on your disk, takes about 63 MB per million files, and never leaves your Mac. You can delete it at any time; the next launch rebuilds it from the two roots.