FinderSearch puts a fuzzy filename index inside a native macOS file browser

The search index is fsearch, vendored into the app rather than bolted on

FinderSearch does not implement its own index. The engine is fsearch by Noah Dunnagan, vendored unmodified at version 0.2.0 under its own MIT license, with third-party notices kept in a dedicated file. That choice explains most of what the app does well. fsearch is a dedicated fuzzy filename indexer, so the matching behaviour, the relevance ranking and the filter syntax come from a tool built for that one job, while the macOS shell around it is written in SwiftUI and AppKit. The repository layout backs this up: a Sources directory, a Tests directory, a vendor directory for the engine, a scripts directory, and a Package.swift at the top level, so the Swift package builds the interface while the search core arrives as a dependency. Everything runs on the local machine. The README is explicit that search runs locally and that files are not uploaded, which for a tool that indexes a user's entire home directory is the first question worth answering.

Fuzzy matching plus filters such as ext:pdf and mtime:<7d

The search surface is the part of the app a keyboard user lives in. Matching is fuzzy rather than exact, results carry a relevance ranking, the search can be scoped to a folder, and the filter syntax supports qualifiers such as ext:pdf and mtime:<7d, which means a query can ask for PDF files modified in the last seven days without a second tool. Those four capabilities work together: fuzzy matching handles the case where the user half-remembers a filename, the ranking decides what appears first when several files are plausible, folder scope keeps a global index from returning noise from unrelated trees, and the filters narrow by attribute once the fuzzy part has found the right neighbourhood. The tag feature listed under the file management group and the mention of tags in the release notes for v0.4.7 show the index carries metadata beyond the name itself, which is what makes attribute filters such as modification time meaningful in the first place.

Icon, list, column and gallery views with Quick Look and restorable tabs

The browsing half of the app is deliberately a macOS file browser rather than a search window with a results pane. Four view modes are offered, icon, list, column and gallery, which are the same set Finder offers, and Quick Look previews come from the system. Tabs restore when the app is reopened, so a working set of directories survives a quit, which is the detail that separates a daily driver from a one-off search utility. File operations are grouped together under getting file work done: drag selection, copy and move, batch rename, ZIP tools, tags, sharing, Trash and undo. The app also shows transfer progress with cancellation, and it presents explicit choices when files conflict during a copy, which is one of the points where a file manager either earns trust or loses it. None of that is exotic, but the combination is what makes the app usable as a daily replacement rather than a demo.

The measured win is in the backend, not the rendered interface

The performance section is specific about what was measured, which is more useful than a headline number. In three warm, exact-filename benchmarks over 10,000 generated files, fsearch returned results in 0.49 to 1.14 ms against 7.06 to 7.30 ms for Spotlight, using median times on an Apple M4. The README then limits the claim to what it actually covers: these numbers measure the search backend including its IPC round trip, not rendered user interface latency. The app itself waits 50 ms after typing stops before it runs a search, and Return submits a pending search immediately, so the keystroke to visible result path is longer than the backend figure. The honest reading is that the index answers faster than Spotlight does, and the interface adds a debounce on top. The benchmark method, results and reproduction steps live in a separate document under docs, which is the right place for a claim like this to be checked.

Installing the app means a DMG, a permission grant and a Gatekeeper exception

There are three installation steps and the third one is the one people miss. You download the DMG, drag FinderSearch into Applications, eject the disk image and open the app. Then Full Disk Access has to be enabled in System Settings under Privacy and Security so the app can search protected folders, after which it must be quit and reopened for the change to take. The app is not yet Developer ID-signed or notarized, so macOS may block it, and the documented path is to choose Privacy and Security and then Open Anyway. The first search index has to be allowed to finish building before results are complete. Because the download link points at the latest release for Apple Silicon and the requirements say macOS 15+, this is an Apple Silicon app in practice. The README notes that Apple Silicon is verified while Intel builds remain unverified, so a machine with an Intel processor is outside the tested envelope.

Building from source pulls in Rust and bundles the engine automatically

The source build needs macOS 15 or later, Xcode 16 or compatible Command Line Tools, and Rust 1.85 or newer with Cargo. That Rust requirement comes from the vendored engine, so a developer cloning the repository needs a second toolchain even though the interface is Swift. The build script handles the engine automatically, so there is no separate step for fetching fsearch, and the resulting app bundle is opened from the dist directory. Tests run with swift test -c release. The repository also carries CONTRIBUTING.md with development checks and a description of the code layout, alongside DESIGN.md and PRODUCT.md, which is a sign that the project treats its internal documentation as part of the deliverable. For anyone planning to modify the app rather than just run it, those three documents are where the design intent lives.

git clone https://github.com/zeusinsight/FinderSearch.git
cd FinderSearch
./scripts/build.sh
open dist/FinderSearch.app

The bundle in the dist directory is what you launch, and the build script has already folded fsearch into it by the time that step runs.

The limits list rules out content search, AirDrop and Finder extensions

The current limits section is short and worth reading before anything else. Content search is not supported, so FinderSearch finds files by name and attributes but cannot look inside them, which is the difference that decides whether it can replace Spotlight for your work. AirDrop is not supported. Finder extensions are not supported, so the app does not plug into the Finder ecosystem the way a context menu extension would. Saved smart folders are not supported either, nor is folder merging, and persistent undo history is missing, so an undo that closes the app is lost. The README also notes that slow disks and cloud providers can still take time. Reading the feature list again with this in mind, the position becomes clear: the app is a fast filename layer with a full file browser wrapped around it, and the missing pieces are the ones that require deeper system integration.

How FinderSearch differs from Spotlight and from a bare fsearch run

Two alternatives are worth comparing, and they fail in different ways. Against Spotlight, the difference is the retrieval mechanism: Spotlight is a system index maintained by macOS across every volume, while FinderSearch queries the fsearch index that the app builds and manages itself, which is why the app needs Full Disk Access and why the first run waits for indexing. The trade goes both ways. FinderSearch wins on the measured warm query time and gains a filter syntax Spotlight does not offer in the same form, and it loses the system-wide reach and the content search that come from indexing file contents. Against running fsearch from the command line, the difference is everything except the matching. fsearch alone gives you a fast answer and a list of paths; FinderSearch adds the views, the previews, the tabs, the file operations and the conflict handling. If your need is a script that resolves a filename, the engine alone is enough.

Editorial conclusion

Mac users who spend their day in large directory trees and want a filename search that responds in under a millisecond, and who are willing to grant Full Disk Access and work around Gatekeeper, are the people FinderSearch is for. It is the wrong tool for anyone who needs content search inside files, AirDrop, Finder extension panels or saved smart folders, since the current limits section lists all four as unsupported, and it is the wrong tool for Intel Macs, which the README says remain unverified. Check three things before adopting it: that your workflow lives in filenames rather than file contents, that you can accept an unsigned and unnotarized application, and that the fsearch index finishes building on your volume, since the app waits for the first index and the README notes that slow disks and cloud providers can still take time. The project is MIT licensed, fsearch is vendored unmodified at v0.2.0 under its own MIT license, and the last push was on 2026-10-15.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zeusinsight/FinderSearch on GitHub