How we made our Mac launcher feel instant by killing slow providers

There's this thing Spotlight does where you press cmd+space, type two letters, and then wait. Not a long wait. But you can feel it. And once you've felt it enough times you stop trusting it for quick lookups. You reach for the trackpad instead, or you remember you have iTerm open already, or you just don't bother.

That little gap between thinking and seeing is the entire reason Raycast exists, and Alfred before it, and now Brow.

I assumed for a long time that the gap was hardware. It isn't. M-series Macs are absurdly fast. The gap is architectural: most launchers wait for the slowest provider before they paint anything. If your file index provider is having a bad morning, the whole UI sits there with you.

So Brow doesn't wait.

Three tiers, three deadlines

Every resolver in the app is assigned to one of three tiers. Each tier has a deadline. Miss it, you're out for this keystroke.

The Instant tier is for things that are basically a dictionary lookup with some parsing on top. Apps, math, color parsing, unit conversion, system commands. We expect these to come back effectively immediately.

The Fast tier is for things that touch an in-memory cache but never disk. Window list, clipboard search, snippets, frecency lookups.

The Deferred tier is everything that's allowed to be slow. Files, browser history, calendar, web search, the AI overview. Disk-bound or network-bound by nature. We never let it block the first paint.

The first frame ships when the Instant tier returns. Fast and Deferred stream in after that. If a resolver is sick today (helper daemon's gone, network's flaky, disk's spinning up), it gets cancelled. The user sees the 59 resolvers that did finish, not the one that didn't.

await withThrowingTaskGroup(of: [Hit].self) { group in
    for resolver in tier.resolvers {
        group.addTask {
            try await withTimeout(tier.budget) {
                await resolver.resolve(query)
            }
        }
    }
}

That's most of it. Structured concurrency does the cleanup for free - cancel the group and every child dies with it. No orphaned tasks waking up two seconds later and trying to push results into a UI that's already moved on.

The ranker is dumb on purpose

People assume the hard part is ranking 60 providers against each other in real time. It isn't. The hard part is keeping the score function cheap enough that the ranker is never the bottleneck.

Every candidate gets an 18-dim feature vector: recency, frecency, co-occurrence, Markov predictions, per-app priors, contextual boosts, a few other things I keep meaning to write down somewhere. The score is just a dot product against a learned weight vector. Vectorized, sub-microsecond per candidate. You can rank thousands and not notice.

The weight vector updates online. Every time you pick result #3 over result #1, the weights for the features that made #3 attractive nudge up. Slow, conservative, no learning rate tuning required.

After two or three weeks your Brow stops looking like mine. Mine ranks iTerm first when I type it. Yours probably won't. Nobody trained anything. It just watched.

No cloud involved. The weights live in a file at ~/Library/Application Support/Brow/ranker.bin. You can delete it. Nothing else holds your data hostage.

The unsexy resolvers are doing all the work

When I started I spent way too much time on the AI overview resolver. Built a whole streaming UI for it. Tuned the prompts. Got the avg latency down to something reasonable.

Then I looked at the telemetry. Almost nobody uses it. (Sorry, AI overview.)

The resolvers people actually live in are the boring ones:

kill chrome, enter. Chrome is gone.

port 3000, enter. Whatever Node process was squatting on that port is dead.

5ft in cm, the answer's already on your clipboard before you read it.

#FF5733, you get a swatch and every format conversion and one of them is selected.

uuid, 3pm in tokyo, 128*3+15%, base64 hello, md5 password, weather, airpods, mute spotify. None of these need anything fancy. They need to be available faster than the cost of deciding which app to open.

I keep wanting to add more clever stuff and the data keeps telling me to make the boring stuff faster.

Where it lands

About 60 resolvers across the three tiers. 18-feature ranker, weights learned locally. No backend in the instant and fast paths. One Swift 6 binary, no Electron, no JS runtime, no 400MB install.

I'm not going to put a benchmark number here because I haven't done the kind of rigorous measurement that would let me defend one with a straight face. What I can say is that it feels different. The result you wanted shows up at the same time the dropdown does, instead of a quarter beat later. Once you've used it for a day you stop trusting Spotlight again.

The Mac is a fast computer. Structured concurrency is free now. If your launcher feels sluggish on this hardware it's almost always because somebody didn't enforce a deadline.

We enforced the deadline.