Raycast vs Alfred

The core is a solved problem, so ignore it in the comparison

Launching applications, finding files, doing arithmetic, converting units, searching the web from a keyword, every serious launcher does these well, and demonstrations of them tell you nothing. Assume parity on the basics and spend your evaluation on the parts you would use on your tenth day, not your first.

The one core detail worth testing is responsiveness under real conditions: with your actual number of files, applications and browser tabs, does the first result appear before you finish typing. A launcher that hesitates gets abandoned, because the entire value is that it is faster than reaching for the mouse.

How you build a custom action is the real divide

One tradition composes automations visually: you assemble triggers and actions on a canvas, wire them together, and drop in a script where the visual pieces run out. It is approachable for people who do not write code daily, and complex flows become large diagrams that are easier to build than to revisit a year later.

The other tradition treats extensions as small programs with a defined interface, which suits anyone comfortable in a code editor: extensions are text, they can be version-controlled and reviewed, and the same skills used at work apply. The cost is that trivial one-off automations carry more ceremony than dragging two boxes together.

Pick by asking what you will build. If the honest answer is a handful of shortcuts for repetitive tasks, the visual approach gets you there sooner. If you expect to build several extensions and maintain them, the programmatic approach ages considerably better.

Distribution, sync and what happens on a second machine

A shared store of ready-made extensions is a genuine multiplier, because the useful automation is usually one somebody already wrote. Look at how extensions are discovered and installed, whether they are reviewed before publication, and what an extension is permitted to access once installed, these run with your privileges and can read what you type into them.

Then check what moving to another computer costs. Whether settings, custom commands and snippets sync automatically or through a folder you manage yourself, whether that requires a subscription, and whether a team can share a common set of commands. If you work across two machines, this is the difference between a tool you configure once and one you rebuild.

Switching costs are muscle memory, so trial deliberately

The main cost of changing launcher is not money or migration; it is that a keystroke you have used thousands of times now does something else. Expect a week of friction regardless of which is objectively better, and do not judge in the first two days, when everything feels worse by construction.

Run the trial properly: list the five things you invoke most, rebuild exactly those in the candidate, bind the trigger to the same key, and disable the incumbent completely for a week. Half-switching produces a permanent muddle in which neither tool is fully configured. At the end, keep whichever you stopped thinking about, that, and not the feature list, is what a launcher is for.