asyar: a desktop launcher written in Rust on top of Tauri

Tauri and Rust instead of an Electron bundle

asyar is described as a fast, open-source launcher for macOS, Windows and Linux, with the tagline about the power of Raycast, the speed of Alfred, and privacy by design.

The architectural decision is stated up front: it is built with Tauri plus Rust instead of Electron. The README spells out what that buys, and the list is specific rather than generic. There is no bundled Chromium and no idle V8 runtime, so memory use is lower. The Rust backend initializes in milliseconds, which is what makes startup feel instant. There is real OS integration through native APIs for app indexing, clipboard, global hotkeys and accessibility. And extensions run in isolated iframes, so a broken extension cannot crash the launcher.

The UI side is Svelte 5, and the project describes the split as native performance with web flexibility, with Rust doing the heavy lifting and Svelte keeping the UI snappy.

The security point deserves more attention than it usually gets. A launcher with a global hotkey, a clipboard history and the ability to run scripts is a program with a lot of authority. Isolating extensions in iframes means a faulty extension cannot take the whole window down, which is a containment model rather than a promise. Privacy by design, in the tagline, is a claim about where the data stays: the feature list is built around local behaviour, from app indexing to clipboard history to scripts, rather than a service.

The benchmark table, and how to run it yourself

The README publishes a comparison table against Raycast 2.6.2.0, and it is unusually specific about its conditions, which is the first thing to check when reading any launcher's speed claims.

| Metric                                 | Asyar 0.1.1-49 | Raycast 2.6.2.0 |
| -------------------------------------- | -------------: | --------------: |
| Hotkey → window visible (median of 15) |        13.9 ms |         22.2 ms |
| Hotkey → window visible (p95)          |        17.3 ms |         32.0 ms |
| Hotkey → window visible (p99)          |        20.5 ms |         32.5 ms |
| Cold start → usable                    |         585 ms |        2129 ms |
| Memory footprint, idle (all processes) |       419.2 MB |        451.5 MB |
| App size on disk                       |          68 MB |          223 MB |

The measurement conditions are given underneath: measured on 2026-10-04 on an Apple M4 Max with 36 GB RAM running macOS 27.0.1, each app as installed, summoned by its own registered global hotkey, one at a time on a quiet machine. The method is described as black-box, a synthetic hotkey press to launcher window on screen.

The better part is that the measurement is not a claim you have to accept. The README points at `benchmarks/bench.sh`, documented in `benchmarks/README.md`, which measures Asyar against Raycast on your own machine across hotkey-to-window latency, cold start, full-process-group memory, idle CPU and wakeups, idle disk writes and app size, and regenerates the table with `--update-readme`. Raycast Beta is included automatically when installed.

There is an honesty note about the privileged rows. The CPU ms/s, idle wakeups and idle disk writes measurements need passwordless `sudo` for `powermetrics` and `fs_usage`, and report `n/a` without it, with the details in the benchmarks README.

That willingness to publish the rows that could not be collected, and the script to reproduce the rest, is what makes the table useful rather than decorative.

Three installation paths, one of them a script

Installation is documented for macOS, Linux and Windows, and the routes differ by platform.

For macOS and Linux the installer is a shell script:

curl -fsSL https://raw.githubusercontent.com/Xoshbin/asyar/main/install.sh | sh

For macOS there is a Homebrew route, and it carries an extra step that is easy to miss:

brew tap Xoshbin/asyar
brew trust --tap xoshbin/asyar   # one-time — Homebrew 6+ requires trusting third-party taps
brew install --cask asyar

For Windows, or for a manual download on any operating system, the README points at the Releases page for the installer for your platform.

The Homebrew note is worth pausing on. Homebrew 6 requires third-party taps to be trusted explicitly, and the command is `brew trust --tap xoshbin/asyar`. If you hit a failure during `brew install --cask asyar`, this is the reason, and it is a change in Homebrew's policy rather than a bug in the cask.

The curl route pipes a remote script into a shell, which is the usual trade for a single line install. If you would rather see what runs, the script lives in the repository at `install.sh` at the top level, and the Windows manual download route avoids the question entirely.

Wayland will not let the launcher take the hotkey

The Linux instructions contain a problem that is worth reading carefully, because it is not a bug in the installer.

The installer places the AppImage at `~/.local/bin/asyar`, with a lightweight summon command beside it at `~/.local/bin/asyar-summon`. The reason for the second file is that Wayland protocol security prevents background applications from intercepting global keyboard shortcuts directly. So on Wayland, the launcher cannot claim the hotkey itself, and you bind it in your desktop environment or window manager instead.

The README then gives the exact binding for four environments. For GNOME, you go to Settings, then Keyboard, then View and Customize Shortcuts, then Custom Shortcuts, click `+`, set Name to `Asyar`, set Command to `asyar-summon` and assign the shortcut. For KDE Plasma, the path is System Settings, then Shortcuts, then Custom Shortcuts or Command/URL, and you add a global shortcut for `asyar-summon`.

For the tiling window managers the configuration is a single line:

bind = ALT, SPACE, exec, asyar-summon

for Hyprland, added to `~/.config/hypr/hyprland.conf`, and the equivalent for Sway:

bindsym Mod1+space exec asyar-summon

added to `~/.config/sway/config`.

So a Wayland user ends up with a launcher that works but with one more moving part than on X11 or macOS, and the extra step is invisible if you only read the headline.

Migrating from Raycast through .rayconfig

Switching from Raycast is treated as a first class path rather than an afterthought. The README says the configuration does not have to be rebuilt from scratch, because the author built an instant importer directly into Asyar.

The mechanism is Raycast's own export. You export your data from Raycast through Export Settings and Data, which produces a `.rayconfig` file, then summon Asyar and search for it. The README lists this as a 1-Click Migration step.

The same section also has to answer the question every switcher asks, which is what else changes. The extension catalogue is the obvious gap, since Asyar's extensions are its own system with extensions running in isolated iframes, and the security model of the two projects is not the same.

The broader feature set is visible in the screenshots section of the README, which lists fuzzy search, AI agents with tool calling, an instant calculator, clipboard history, MCP servers, window management, snippets, scripts, extensions, browser integration, keyboard shortcuts and settings.

Two of those deserve a note. MCP servers means the launcher can host Model Context Protocol servers, which places it in the path of agent tooling rather than being only a search box. Scripts and browser integration are the features that make a launcher a work tool rather than a launcher for applications, and they are also the two that carry the most authority on your machine.

A monorepo with the SDK versioned separately

The repository layout shows a workspace, and the release tags show how the pieces are versioned independently.

The top level contains the Rust and application code in `asyar-launcher/`, the extension builder in `asyar-ext-builder/`, and the SDK in `asyar-sdk/`. There is a `benchmarks/` directory holding the measurement script, `docs/` with the documentation images, `scripts/` for the build and check tooling, `install.sh` at the root, `setup.mjs` for the first-run setup, and a `rust-toolchain.toml` that pins the Rust version used by the project. There is also a `package.json` with `pnpm-workspace.yaml` and `pnpm-lock.yaml`, plus `.husky/` and lint-staged configuration for commit hooks.

The tag list is where the versioning split shows. Alongside the application tags v0.1.1-51 and v0.1.1-50 there is a separate `sdk-v4.15.0` tag, published on the same day as v0.1.1-51. So the extension SDK has its own major version line, at 4.x, while the launcher application is still at 0.1.x. An extension author pins the SDK version, and the launcher and the SDK evolve on different schedules.

The scripts in package.json show how the project is developed and checked. There are `dev`, `build` and `build:all` scripts driving `scripts/dev.mjs` and `scripts/build-all.mjs`, a `check` script, and separate CI checks for the frontend and for Rust, with `check:ci:changed` for a subset. Formatting uses prettier with a Svelte plugin, and `husky` is installed as a prepare hook.

The root package.json is marked private with version 0.0.0 and declares Node 20 or newer and pnpm 10.26 or newer, which are the requirements for working on the project rather than for running the launcher.

GPL-3.0 terms and a version number that says early

The licence field on the repository says GPL-3.0, and there is a LICENSE file, a FUNDING.yml, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a RELEASING.md at the top level.

GPL-3.0 is the licence to look at carefully before you adopt a launcher. A copyleft licence carries obligations for anyone who distributes the program, and for a desktop launcher distributed as a binary, the practical question is what the obligations mean for your build and your distribution channel. That is a question for your own counsel, but it is materially different from the permissive terms most launchers carry, and it is the first thing to check rather than the last.

The version number is the other honest signal. v0.1.1-51, with the build number appended, says this is a project in its first public iteration with many successive builds. The SDK sits at 4.x, which suggests the extension API has been through more shape changes than the application itself.

On maintenance, the numbers are current. The last push was on 2026-10-19, the most recent application tag v0.1.1-51 was published on 2026-10-12, and the SDK tag sdk-v4.15.0 went out the same day. The project is being worked on daily.

The homepage is asyar.org, and the project also runs a Discord community linked from the README. For an adopter the combination is a fast moving, copyleft licensed, actively built launcher with an open benchmark you can run yourself, and both halves of that sentence are reasons to check the licence and the release notes before you install it widely.

Editorial conclusion

Adopt asyar if you want a launcher that stays local, starts fast and runs its extensions in isolation, and you are willing to live with a 0.1.x version number and a project that is still filling in its feature set. Skip it if you need the full breadth of the Raycast extension catalogue today, since the migration importer is the only documented bridge and the version number suggests the surface is still moving. Verify first by running `benchmarks/bench.sh` on your own machine rather than trusting the published table, and check the Wayland shortcut binding on Linux, where Wayland protocol security is the reason the launcher cannot grab the hotkey itself. The licence field on the repository says GPL-3.0, and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Xoshbin/asyar on GitHub