look is a keyboard-first launcher with a Rust core and three different shells

One core and three different ways to draw a window

look is a keyboard-first, local-first launcher for macOS, Windows and Linux, and the sentence that sells it is about what it does not do. Open apps, files, folders, clipboard history and quick commands without leaving the keyboard.

The architecture is stated just as plainly. Results land as fast as you can type, with a Rust core under a native SwiftUI app on macOS, and a GPU-drawn gpui shell on Windows and Linux, with no browser engine in the process. No background daemons, and the index, clipboard and history stay on your machine, with no telemetry.

That is an unusual set of choices for a launcher, and each of them has a reason. A Rust core means the search and indexing logic is the same code on three platforms rather than three implementations that drift. A native shell means the window is not an Electron app, so it does not carry a browser engine in every process, which is where most launchers spend their memory. No background daemons means the cost is paid when the window opens rather than all day. And no telemetry is a privacy choice stated in the same breath as the local-first claim.

The implementation language recorded for the repository is Rust, the licence is GPL-3.0, and the last push was on 2026-10-19.

The comparison it publishes, including the row where it loses

The readme contains a comparison table with Spotlight, Raycast, Alfred, ulauncher and rofi, and the honest thing to do is read all of it, including the row where look is on the losing side.

What look claims is a GPLv3 licence, a free product with no paid tier, no account needed, and clipboard history for text and images. On the platform row it covers macOS, Windows and Linux, where Spotlight and Alfred are macOS only, Raycast is macOS and Windows, and ulauncher and rofi are Linux only. The open source row has look, ulauncher and rofi marked as open, and Spotlight, Raycast and Alfred as not.

The commercial row is the one people argue about. Raycast has a Pro tier at 8 to 10 dollars a month, and Alfred has a Powerpack at 34 pounds, while look, ulauncher and rofi are free. The account row notes that Raycast needs no account for its core but does for sync and AI.

And the extension store row is where look comes out behind. Raycast and Alfred have one, ulauncher has one, and look does not. The clipboard history row is the one where look is ahead of the field, since Spotlight only has it on macOS 26 and later, Raycast's free tier keeps it for three months, and Alfred has it only through its Powerpack, while the Linux launchers do not.

The readme is also candid about why you would use it. If this is useful, star the repo, because it is the single biggest signal that helps the project keep shipping. That is a small thing, but it says the project has no other funding or distribution mechanism, and it is worth knowing before you depend on it.

macOS: a signed cask, and only one architecture

The macOS install is one command.

brew install --cask look

Then you bind Cmd+Space to Look, which means disabling Spotlight's shortcut in System Settings, Keyboard, Keyboard Shortcuts, Spotlight, or you pick another shortcut with launcher_hotkey in the config file at ~/.look/config.

Two details matter for anyone who distributes this to a team. Release builds are signed and notarised, so no Gatekeeper bypass is needed, which removes the usual friction on macOS. And releases are one build per architecture, with only the Apple Silicon build published today. That is a hard limit rather than a preference, and it is worth checking before you hand it to a fleet of Intel Macs.

There is a Nix route as well, with a flake install.

nix profile install 'github:kunkka19xx/look?dir=apps/linows'

The reason to use it rather than a plain build is stated: it is the same signed and notarised bundle Homebrew ships, so the Accessibility and Automation grants survive an update. The macOS permissions the launcher needs, which are the ones for window focusing and reading the clipboard, are tied to the binary, and if the binary changes on update the grant has to be given again.

For nix-darwin and Home Manager there is a separate build document, and the same reasoning applies there.

Linux has four install routes and one architecture

Linux is the platform with the most routes, and the same constraint as macOS, inverted.

Released artifacts are x86_64 only. ARM builds are not published, and the readme says to open an issue if you need one. So the two platforms between them cover the two common architectures, but not in a portable way, and a Raspberry Pi user is out of luck.

For Arch there is an AUR package, installed with an AUR helper.

yay -S look-bin

Or without a helper, by cloning the AUR repository and running makepkg. For Ubuntu and Debian there is an install script.

curl -fsSL https://raw.githubusercontent.com/kunkka19xx/look/main/scripts/linux/install-look.sh | bash

Or you download the .deb from the releases and install it with dpkg. And for any distribution there is an AppImage.

chmod +x Look_*.AppImage
./Look_*.AppImage

The AppImage is the simplest route and the least integrated, since it is not on the system path, which is why the readme tells you to launch it with lookapp from a terminal or to find Look in your app launcher.

NixOS is supported through the same flake, and also declaratively, with a module and a programs.lookapp.enable setting that includes a binary cache.

The uninstall section is equally thorough, with a remove command for each of the package formats and a note that the AppImage is uninstalled by deleting the file.

Compositors get different treatment, and niri gets none

The most detailed part of the documentation is about how the hotkey and the window get registered on a tiling window manager, and the differences are not cosmetic.

Autostart via .desktop files only works on full desktop environments such as GNOME and KDE. On standalone window managers you add Look to the configuration by hand. On i3, sway and Hyprland the Alt+Space hotkey and the window rules, float and no border, are registered automatically at runtime, so you only need the autostart line.

# i3: ~/.config/i3/config
exec --no-startup-id lookapp

# sway: ~/.config/sway/config
exec lookapp

# Hyprland: ~/.config/hypr/hyprland.conf
exec-once = lookapp

The comments in that block explain the mechanism. On i3 the Alt+Space key works through the X11 global shortcut plugin, on sway and Hyprland the hotkey and the rules are injected at runtime via swaymsg and hyprctl respectively.

niri is the exception, and the readme is clear that niri has no API to add binds at runtime, so the hotkey has to go into the config file yourself. Look prints the exact stanza on first run, including the gdbus call it uses to ask its own desktop service to toggle the window.

spawn-at-startup "lookapp"

binds {
    Alt+Space allow-inhibiting=false { spawn "gdbus" "call" "--session" "--dest" "com.look.Desktop" "--object-path" "/com/look/Desktop" "--method" "com.look.Desktop.Toggle"; }
}

The allow-inhibiting=false part has a specific purpose, and it is a good example of the kind of detail that only shows up in real use. Without it, niri passes the key to a window holding a keyboard-shortcuts inhibitor, and fullscreen games, browsers and virtual machines all take that inhibitor, so the launcher never opens over them.

On GNOME there is a Shell extension, used for window focusing and the hotkey on Wayland, and the readme asks you to log out and back in after the first install so that extension can load.

Where the repository keeps its parts

The top level listing shows a project with several distinct pieces under one roof.

There is core/, which is the Rust core that the search and indexing logic lives in, and apps/, which holds the platform applications, with apps/linows/ being the one the Windows Tauri build and the Nix flake point at, which is why the flake URL carries a dir parameter. There is bridge/ for the interface between the core and the shells, tools/ for the developer tooling, packaging/ for the distribution artefacts, scripts/ for the install scripts, including the Linux one the README tells you to pipe into bash, and assets/ and docs/ for the icon and the user guide.

The build system is a top level dispatcher Makefile, and its comment explains the arrangement. Any target is run the same way on either operating system, for example make app-build, and the file includes the OS specific Makefile from scripts/, choosing scripts/Makefile.win on Windows and scripts/Makefile.mac otherwise. The two platform builds are therefore genuinely different, one with Xcode on macOS and one with Tauri under apps/linows/ on Windows, which is what the comment about the two explicit invocations points to.

The repository also carries a CLA.md, a CONTRIBUTING.md, a DEVELOPMENT.md, a .pre-commit-config.yaml and a .cargo/ directory. The releases come often and with descriptive names, v0.7.2 Compact mode on 2026-10-03, v0.7.1 We're on homebrew-core now on 2026-09-23, and v0.7.0 Your clipboard and Launch mode on 2026-09-23, which tells you both how recently it moved and what the recent work was.

Editorial conclusion

Adopt look if you want Spotlight style search on Linux and Windows, and you care more about a local-first tool with no account and no telemetry than about a plugin ecosystem. Do not adopt it expecting the extension store of Raycast or Alfred, because the comparison table in its own README marks that as the row where it comes out behind. Verify first which binary you can actually get, since the macOS release is Apple Silicon only today and the Linux artifacts are x86_64 only, and read the compositor notes if you run a tiling window manager, because the hotkey registration differs between i3, sway, Hyprland and niri.

Frequently asked questions

Official sources

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