DEV Community: Serhiy

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

Serhiy — Tue, 26 May 2026 18:00:18 +0000

``
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.

`swift 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.

Try it

brow-app.com. Free, macOS 14+. Runs fine next to Spotlight or Raycast - I still have all of them installed because old habits.

If you try it and find a query that feels slow, tell me which one. We'll figure out which tier it landed in and why.

(The other half of the story, why this is Swift instead of Electron, is here.)

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

Serhiy — Tue, 26 May 2026 18:00:18 +0000

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.

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 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.

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

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.

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.

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.

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.

Try it

brow-app.com. Free, macOS 14+. Runs fine next to Spotlight or Raycast - I still have all of them installed because old habits.

If you try it and find a query that feels slow, tell me which one. We'll figure out which tier it landed in and why.

(The other half of the story, why this is Swift instead of Electron, is here.)

Brow (Why We Built Brow in Swift, Not Electron)

Serhiy — Fri, 20 Mar 2026 16:30:39 +0000

A lot of Mac utilities talk about speed.

What matters more is why they feel fast, where the limits come from, and what trade-offs the architecture creates later.

That was one of the earliest decisions behind Brow: build it as a native Swift app from day one.

Not because “native” sounds good in marketing.

Because for the kind of product we wanted to build — launcher, notch layer, system utilities, hardware-aware modules — architecture changes what is possible.

The real question was never just “Swift vs Electron”

The real question was:

Do we want a Mac app that happens to run on macOS, or a Mac app that is built for macOS from the inside?

Electron is a valid choice for many teams. It optimizes for one codebase, faster iteration, and easier cross-platform shipping.

Raycast took a different route. Its app is native, but its extension ecosystem is built around React, TypeScript, and Node so developers can build on top of it quickly.

That is a smart trade-off.

But it is still a trade-off.

We wanted a different one.

Where the difference starts to matter

If you compare products like Brow and Raycast, the real difference is not just “which launcher is faster”.

The deeper difference is this:

how much of the product sits directly on native macOS frameworks
how much UI or extension logic depends on web tooling
how much low-level system behavior you can control directly
how much overhead you carry as the product grows

That architecture decision affects everything after it.

Why we chose Swift for Brow

We built Brow in Swift because we wanted the critical path to stay native.

That means no Electron shell, no Chromium runtime, and no browser stack in the core app flow.

For us, that mattered for four reasons.

1. Native system access is not a nice-to-have

Once you move beyond “open apps and search commands”, launcher products start touching awkward parts of the OS:

window management
clipboard pipelines
display control
hardware stats
menu bar behavior
screenshot flows
accessibility hooks
notch-adjacent UI

These are not areas where web-style abstraction helps much.

They are areas where being close to AppKit, Swift, macOS services, and system APIs matters.

This does not mean every Mac app must be written fully in Swift.

It means that if deep OS integration is central to the product, native architecture compounds in your favor.

2. Extension velocity and product coherence usually pull in opposite directions

This is one of the most interesting trade-offs in tools like Raycast.

A React/TypeScript-based extension system makes extension development much more accessible to web developers.

That helps ecosystem growth.

But it also means the platform has to constantly mediate between:

native host behavior
extension runtime constraints
API boundaries
consistency across third-party commands

That model is great for extensibility.

It is not automatically great for tight, system-level product design.

We wanted tighter control over behavior, performance envelopes, and module integration — even if that meant a slower road to ecosystem scale.

3. “Fast” is not only about launch time

People often reduce desktop performance to one thing: how quickly the window appears.

That matters, but it is only the surface layer.

The more important questions are:

How much memory does the product carry at idle?
What happens when multiple modules are active?
How much work is happening in the background?
How direct is the rendering path?
How many layers are sitting between intent and UI update?

For us, the goal was simple:

keep the stack small, direct, and native.

That is the advantage of building the core this way.

4. The longer-term constraint is complexity, not initial speed

Web-heavy architectures often win early.

They are easier to prototype, easier to staff, and easier to ship across platforms.

But the question we cared about was not:

What gets us to v1 fastest?

It was:

What architecture do we still want when the app becomes much more ambitious?

Because once a launcher becomes a platform, every abstraction starts charging rent.

That rent appears as:

more edge cases
more memory pressure
more runtime boundaries
more UI inconsistency
more special handling for modules that do not quite fit

Native code is not magically simple.

But for a Mac-only product, it can keep the stack more honest.

Is Brow better than Raycast?

That depends on what you value.

Raycast has a strong ecosystem, a mature extension story, and a smart developer adoption strategy.

But our argument is narrower:

For the kind of product Brow wants to be, staying fully native in the core gives us better foundations.

Not universally better.

Better for:

deep macOS integration
tighter control over performance behavior
lower architectural overhead in the core path
building features that feel like part of the OS, not layered on top of it

That was the point of choosing Swift.

The trade-off we accepted

This path is slower.

The ecosystem is smaller.

The tooling is narrower.

Some things are harder than they would be in web stacks.

But you also get something important in return:

a product whose architecture matches its platform.

For Brow, that trade was worth it.

Original posts: