Behind the app · Jun 20, 2026
2 min read · Trevor Edwards

Why we used Spotlight instead of building our own file index

Building a custom file index sounds like the "real" way to do fast file search. It is also a second copy of your filesystem to keep correct, forever.

Fast file search feels like it should mean building your own index: walk the filesystem, store paths and metadata somewhere efficient, keep it updated as things change. It is the approach that looks the most like "real engineering."

It is also a second source of truth

A custom index has to track every file creation, move, rename, and deletion, forever, or it silently drifts out of sync with what is actually on disk. macOS already solves that problem continuously, system-wide, for every app - including Spotlight's own search UI.

So HyperKey's file search mode queries Spotlight's existing index directly instead of maintaining a parallel one. It is a boring choice, and boring was the point: less code to get wrong, no background indexing process eating CPU on first launch, and results that are always as fresh as the OS's own.

Boring beats clever here

  • No indexing pass on first launch, no waiting for a fresh install to "warm up."
  • No drift between what HyperKey thinks exists and what is actually on disk.
  • One less system to test, maintain, and eventually debug at 2am.

Building the clever version would have been more fun to write. Riding the boring one is why file search stayed reliable.