Short answer first, the boundary underneath.
Rust today, compiled to a WebAssembly component. Ordinary Rust with one rule: import only krate:* interfaces, never wasi:*. That rule is what keeps an app to tens of kilobytes and inside its sandbox.
krate check-app is the oracle. It compiles the crate, confirms the imports, runs it once headless and paints a frame, then names the stage and the fix if any of that fails.
krate port reads your project and reports what maps cleanly, what needs a capability, and what will not work. It is read-only: it never builds, runs or edits your source.
Pure Rust crates generally carry over. Anything reaching the operating system directly does not, because that is what the sandbox exists to prevent; Krate offers the same capability through its own interface instead.
Working today: windows and widgets, 2D canvas and GPU rendering, audio in and out, speech to text, camera, scoped filesystem, HTTP and WebSockets, key-value and SQL storage, clipboard, dialogs, notifications, gamepads.
Not yet: text to speech, printing, multiple windows, serial and Bluetooth, screen capture, tray icons. Anything needing heavy GPU work is early. The capability list is fixed and public, so you can check before you spend a weekend.
The app does not call AppKit, Win32, or Linux APIs directly. It calls Krate interfaces, and the Krate player on each operating system translates approved calls into local behavior.
The .krate file carries the WebAssembly component and its requested access. It is one portable app, and the same bytes run on all three desktops.
A browser link is the right answer when an app fits inside the browser. Krate is for local software: it works offline, it works next year even if the sender disappears, and “it cannot use the network” is enforced on your machine by the runtime.
An Electron app ships a browser engine and still needs platform packaging. A Krate app is a WebAssembly component: no bundled browser per app, and the shared player controls its access to the computer.
Krate checks every operation at the boundary, so the list is not something the app writes about itself: if the app tries something that was not granted, the call is denied before it reaches the operating system.
If a required permission is denied, the app refuses to start and explains what is missing.
Not yet. The capability boundary is working and useful, but Krate is young and we are not claiming production hardening against hostile third-party code today.
Open apps from people you know, or from the gallery. The current limits and threat model are public.
Krate is the player: the stable layer that makes one app file portable and enforces its access -- like a media player for movies. Without it, every app would have to bring its own engine and operating-system code, and the small-file story would die.
They install Krate once, about 11 MB on macOS. After that, every .krate anyone sends them just opens, through the same permission flow.
Rust calls a package a crate, so the similarity is real. Krate uses a different spelling and refers to the portable container that carries an application and its requested access.
We keep the distinction explicit wherever Rust developers could reasonably confuse the two.