A Technical Deep Dive Into the New Raycast - Raycast Blog

StoreProAIiOSWindowsTeamsDevelopersBlogPricing<br>Log inDownload<br>Log in

A Technical Deep Dive Into the New Raycast<br>The story behind Raycast's cross-platform rewrite and the details that make it feel fast, delightful, and familiar.

May 14, 2026

We've just shipped the public beta of Raycast 2.0. It's the biggest release since we first launched Raycast back in 2020, and the first version that runs on both macOS and Windows.

Raycast 2.0 on macOS and Windows

To get there, we rewrote the app from the ground up. A new architecture and a stack that mixes TypeScript, Swift, C#, Rust, Node, and React. Web technologies have been part of Raycast from the start, powering extensions and Notes. In v2, we doubled down, while keeping the app feeling as native and fast as it always has.

If the launch post was about what's new, this one is about how it's built. The story behind the rewrite, the calls we made along the way, and what it took to pull off a rewrite of this size. The hard part wasn't making Raycast run. The hard part was making it feel right.

Where we started

Raycast v1 was, at its core, a native macOS app built with Swift on top of AppKit. We almost never reached for standard UI components. They weren't built for the kind of keyboard-first, power-user workflows we cared about, so we built our own. Every list row, every shortcut, every default behavior was handled by us. We didn't make a lot of use of SwiftUI either. It matured in parallel with Raycast and never quite cleared our bar for performance and control. The one place it lives in v1 is the yearly Wrapped feature, which is well isolated from the rest of the app.

Overview of Raycast v1

The extension ecosystem sat on a different stack entirely. React, TypeScript, and Node.js, with the UI described declaratively and rendered by the native app. Felix wrote about the architecture in detail here. Choosing a familiar tech stack for third-party developers is a big part of why the store now has thousands of extensions covering almost every tool people use. The API was also designed to be portable. Nothing about an extension assumed it was running on macOS, which allowed us to bring a big part of the catalogue to Windows last year.

Raycast Notes was the first time we used a web view for a major feature in the app. The editor is a React app mounted inside a web view of a native window. It was a test of whether we could build a surface entirely with web tech without breaking the feel of the rest of the app. It worked and Notes is used daily by a big chunk of our macOS and iOS users.

While v1 was a native app at the core, we've always reached for web technologies when they were the right fit. At the end of the day, people enjoy Raycast because of how it feels, not because of what's under the hood.

Why the rewrite

In late 2023 we started thinking about bringing Raycast to Windows. It was always the plan, from day one, but in the early days we wanted to focus on a single platform and nail the experience there before even considering expanding.

By that point, Raycast had also grown from a launcher into a broader productivity platform, with AI Chat, Notes, extensions, sync, file search, and more. The original architecture, built for a launcher, was starting to limit what we could build next. Compile times were creeping up, AppKit was getting in our way more often, and finding people who could go deep on native macOS was getting harder. Even if Windows wasn't on the table, we'd have needed to rethink most of this.

So we set out to figure out the stack for both the new Windows client and the existing macOS one. But first, any project like this needs a good code name. We called it "X-Ray", which stands for cross-platform Raycast.

Picking a stack

We started by looking at what's available for building native apps on Windows – and the state of native UI frameworks there, frankly, is far from great. Microsoft has a history of introducing UI frameworks and then moving on. WPF, UWP, and now WinUI 3, which is still fairly young and not widely battle-tested. If building a polished native app on macOS with AppKit is already challenging, doing it on Windows with WinUI 3 felt like a much bigger risk. Also, the idea of running two independent native apps made us uneasy, considering that most of Raycast's extensions should work identically on both platforms. Maintaining two separate UI stacks would mean twice the work without moving any faster.

That ruled out the fully native route pretty quickly. And since the majority of Raycast's codebase is UI, we couldn't just share a backend and build independent frontends per platform. This pointed us toward a web-based stack. It gives you cross-platform UI by default, a massive ecosystem of libraries, great developer experience, and a talent pool that's orders of magnitude larger than native desktop. Raycast extensions were already built on the web stack and it had been...