DEV Community: Serhiy

ChatGPT started recommending my Mac app

Serhiy — Sat, 06 Jun 2026 09:07:11 +0000

I was scrolling the acquisition report for Brow, my Mac app, when I hit a row that wasn't there a few months ago.

chatgpt.com

Real people, real clicks. Somebody asked ChatGPT something like "best app to manage menu bar icons on Mac" or "a good Spotlight alternative for macOS," and the answer came back with Brow in it, by name, with a link.

For context: Brow is a Mac launcher that also tidies your menu bar, keeps your clipboard history, and bundles a stack of small utilities. So those are exactly the questions I'd want it surfaced for. I just never expected a model to do the surfacing.

I never pitched ChatGPT. No form, no ad slot, no deal. The model picked Brow on its own.

The numbers

30 downloads in 5 days, attributed to ChatGPT. Zero before this spring.

Two things matter more than the size.

It went from a flat zero, for the whole life of the site, to a number that now shows up every week. Nothing to something is the only jump that counts.

And these people convert. A Google click is still shopping. A ChatGPT click already got told "use this one" by an advisor they trust, so they land sold. A surprising share install. Cold search traffic doesn't behave like that.

How to test it without fooling yourself

You can probe the model, but only from a logged-out incognito session. No account, no memory, no custom instructions.

Ask from your own ChatGPT and it already knows you, so it tells you what you want to hear. A clean session answers cold, the way it would for a stranger who's never heard of you. That's the only answer worth trusting, and it's the first thing people get wrong when they "test" whether AI recommends them.

We took it further and built an internal tool that runs a batch of realistic prompts on a schedule and logs two things: which apps get named, and which source URLs the model cites to back the pick. So we watch which resources actually get picked up instead of guessing. The early patterns are interesting. I'll write them up once there's enough signal to say something solid.

What actually moves it

The model learned about Brow from the open web: the site, the App Store page, a few blog posts, the odd Reddit thread. It compressed the internet's opinion of Brow into a sentence and handed it back. So "optimizing" is old-school:

Say plainly what the app does, on a page a crawler can read. The model can only recommend Brow as a "menu bar manager" or "Spotlight alternative" if the web already ties those words to it.
Earn real mentions. Reviews, threads, word of mouth. That's the training signal, and there's no shortcut around humans liking it first.
Don't keyword-stuff. Models smell it, and those visitors bounce hardest.

Then the plumbing, because the model only knows what got indexed:

IndexNow via Cloudflare (one toggle, still in beta) so content changes hit the index immediately instead of waiting for a crawl.
Bing Webmaster Tools + Search Console, both domains, to see real queries and confirm pages are even indexed.
Study competitors' results, not their rankings. What queries they own, what rich snippets and sitelinks they pull, what their landing pages look like.
Review domains. Sites with "reviews" in the domain name rank hard and feed the model dense social proof. Getting Brow onto the right ones is on the list.

Why a small number is worth a whole post

Thirty downloads won't change my month. But how people find software is splitting in two: the old pile of blue links, and a model deciding whether to say your name, trained on data you can't see, handing you back one anonymous row after the fact.

Most people find out it stopped saying their name by accident, months later. We stopped leaving that to chance and started watching the prompts directly. We can see it move now, and there's a lot more to say once the monitoring has run a while.

More soon.

(Brow is a Mac launcher, menu bar manager, and clipboard tool: brow-app.com)

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 vs Raycast: An Honest Comparison

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: