Krate portable software, explained simply
Plain English explainer

What if software travelled like a PDF?

You do not download a different PDF for Mac, Windows, Linux, Android, and iPhone. You just open the file. Krate is trying to make apps feel more like that: one portable app artifact, with clear permissions, running through the right host adapter for each machine.

The normal problem

Today, an app is usually married to the operating system it was built for. A Windows app expects Windows APIs. A macOS app expects macOS APIs. A mobile app expects a completely different world.

That means developers often rewrite the same idea several times, or carry a complicated build matrix forever.

Krate asks a different question: what if the app talked to one common layer, and that layer translated to the host underneath?

Files already work this way
PDF One file. Different devices open it with their own viewer.
Typical app Different builds. Different APIs. Different permission behavior.

Krate is not saying apps are as simple as PDFs. It is saying software should have a portability layer that makes the app less tied to one host.

The Krate idea in one picture

App sourceThe developer writes the app in Rust, TypeScript, Go, or another language.
down
WebAssembly componentThe app becomes one portable artifact. This is the file Krate runs.
down
Krate runtimeThe local engine loads the component and connects it to Krate APIs.
down
UAPI + UCapUAPI is the common app API. UCap checks what the app is allowed to do.
down
Host adapterThe adapter translates approved calls to macOS, Windows, Linux, mobile, or web behavior.

Example: how `krate-clock` becomes terminal output

App code `krate-clock` source The sample app asks for time, locale, timezone, and stdout. In simple terms: "What time should I show, and where do I print it?"
Portable file WebAssembly component The app is compiled into `krate_clock.wasm`, a portable artifact that the Krate runtime can load.
Runtime `krate run` The CLI starts a runtime session, loads the component, applies test time/locale flags, and connects the app to UAPI.
UAPI Time, locale, stdout The app calls Krate APIs instead of directly calling macOS, Windows, or Linux APIs.
UCap + adapter Check then translate Krate checks allowed capabilities, then the host adapter provides normalized time, locale, and output behavior.
Output Terminal result `app=krate-clock`, `timezone=UTC`, `locale=en-US`, `date=1970-01-15 06:56`.

This is a small example, but it shows the complete shape: portable app artifact, Krate runtime, common APIs, capability checks, host adapter, and final output.

After Phase 2: what Phase 3 should unlock

Phase 2 proves the runtime path with CLI apps. Phase 3 should prove that the same model can power a real desktop app with a native window, user interaction, and explicit host permissions.

From CLI proof

1
Terminal outputToday, `krate-clock` prints a stable result to the terminal.
2
Small UAPI surfaceTime, locale, files, network, and I/O are the first useful host capabilities.
3
Permission proofKrate can show, grant, deny, and record host access.

To desktop app proof

1
Window UAPIThe app asks Krate for a window, layout surface, events, and drawing.
2
Desktop adaptermacOS, Windows, and Linux adapters translate that into native windows.
3
Same app modelThe app still uses one artifact and explicit capabilities instead of becoming three separate desktop apps.
Krate desktop preview
One WebAssembly app, native host window, explicit permissions.

In simple terms: Phase 3 should move Krate from "a safe portable CLI app can run" to "a safe portable desktop app can open a real window and respond to users."

Current progress: the macOS prototype can create an opt-in AppKit window, attach a first draw view, collect native window callbacks, and process one non-blocking event-loop tick. The runtime can request that AppKit path by name, and there is a local smoke command that opens the native path, pumps one tick, checks the report, and closes it. Linux and Windows now have guarded Winit prototype boundaries, a session owner scaffold, and a callback collector bridge, which means future Winit handlers have a tested inbox for resize, focus, scale, redraw, and close callbacks. Real Linux and Windows windows are still next. The normal path still stays headless for safety.

What is Krate able to do today?

Krate is pre-alpha, but the current Phase 2 proof is real. The CLI can run WebAssembly components that call Krate for time, locale, files, terminal output, and a first local HTTP path.

The most important proof is not just "it runs." The important proof is that host access can be declared, granted, denied, and tested.

Current proof moments
manifest explain krate-cat fs.read:fixtures/** requires a launch grant run without file grant permission denied: fs.read:fixtures/** run with file grant hello from Krate run curl with network grant portable runtime response

Technical terms, translated

WebAssemblyA portable program format. In simple words: the app becomes a file that a runtime can execute on different machines.
RuntimeThe local engine that opens and runs the app artifact. For Krate, this is the `krate` CLI/runtime.
UAPIUniversal API. Instead of asking macOS, Windows, or Linux directly for files or network, the app asks Krate.
UCapUniversal Capabilities. The permission layer. It checks whether the app was granted file, network, time, or other host access.
Host adapterThe translator. It turns approved Krate calls into native operating system calls.
ManifestA small file that says what the app is and what permissions it needs.

What happens when an app reads a file?

1

The app asks

The WebAssembly component calls the Krate file API.

2

Krate checks

UCap checks whether this run granted `fs.read` for that path.

3

The host acts

If allowed, the adapter reads the file through the native OS. If not, the app gets permission denied.

Where the roadmap goes next

Phase 1Proved the base runtime path with a small WebAssembly component.
Phase 2Builds UAPI, UCap, manifests, and CLI sample apps.
Phase 4Mobile hosts: start adapting the model to iOS and Android.
Phase 5-6SDK polish, app bundles, signing, updates, and distribution.
Phase 7Hardening toward a real public platform.

The honest status

Krate is not a finished universal app platform yet. It does not have production GUI, mobile, app bundles, marketplace, or hardened third-party sandboxing.

What it does have is a credible pre-alpha runtime proof: portable components, a real UAPI slice, explicit permissions, denial behavior, sample apps, and evidence tracking.

One sentence

Krate is building the runtime layer that lets software run more like portable files: one artifact, explicit permissions, host adapters underneath.