Human-first · Agent-native · Local by design

Racket for logic. Real native apps.

Rivet embeds Racket CS inside first-party native apps and gives coding agents a machine-readable, deterministic development loop.

Racket backend — declare once
backend.rkt
#lang racket/base (require rivet/backend) (define-event progress) (define-state counter : Int64 0) (define-rpc (greet [name : String] : String) (format "Hello, ~a!" name)) (define-rpc (increment [value : Int64] : Int64) (add1 value))
Generated client — call natively
App.swift — generated by raco rivet build
// typed Swift, generated at build time let text = try await backend.greet(name: "Rivet") // "Hello, Rivet!" let next = try await backend.increment(value: 41) // 42 backend.onProgress { pct in // events arrive as typed values }
PRODUCT IN CONTEXT · 产品如何工作

一份 Racket 逻辑,三种真正的桌面宿主。One Racket core. Three first-party desktop hosts.

直接画出跨平台结构:Racket 负责领域行为,RVT1 连接原生宿主,而不是用一个虚构的 UI 截图解释框架。A direct architecture view: Racket owns the domain behavior; RVT1 connects native hosts. No fictitious product screenshot.

RACKET · DOMAIN CORE
Typed methods and state
RVT1 contracts
Build & acceptance
NATIVE · PRESENTATION
macOS · SwiftUI
Windows · WinUI 3
Linux · GTK4
定义契约Define让能力有可检查的接口Define checkable capabilities
生成桥接Bridge用类型化通信连接宿主Connect typed native hosts
分别验收Verify在各平台验证原生交互Verify packaged native interactions

架构或工作流程示意,非当前 GUI 截图;实际可用能力以项目文档和验收记录为准。Architecture/workflow illustration, not a current GUI screenshot. Refer to project docs and acceptance evidence for available capabilities.

Why Rivet

Racket is great at logic. Commercial apps need native UI.

There was no direct path from a Racket backend to the modern first-party desktop stacks. Rivet fills that gap.

First-party native UI

WinUI 3 on Windows, SwiftUI/AppKit on macOS, and GTK4 on Linux — each platform stays itself.

One backend contract

Typed RPC, events, shared state, cancellation and lifecycle over the same RVT1 protocol, projected into the shared Keel contract.

Generated native clients

raco rivet build generates typed Swift, C++, and Kotlin APIs from your declarations.

Embedded Racket CS

The Racket runtime lives inside the application process — no external backend to manage.

Exact runtime matching

Rivet requires Racket 9.0+ (CS), stages the installed runtime exactly, and never silently falls back to a nearby version.

Safe threading by design

The native side only sees framed RVT1 messages and generated values.

Real-time charts

Rolling-time-series native chart widgets on every desktop host, over one typed data plane.

Updates built in

Signed release feeds on every desktop — bundle swap on macOS, MSI handoff on Windows, AppImage replacement on Linux.

Linkable packages

Hosts link released packages — SwiftPM on macOS, static libraries on Windows and Linux — never compiled sources.

Positioning

Two projects, two trade-offs.

The Racket desktop stack: Rivet and Glaze — different trade-offs, not replacements for one another.

Rivet Glaze
UI stack WinUI 3 / SwiftUI / GTK4 HTML/CSS/JS + WebView
Native widgets first-party OS UI no
One UI codebase no yes
Best fit platform-native commercial apps web-tech desktop apps

Build one verifiable result.

先完成一个可验证的结果。

Choose Rivet when first-party native interaction is worth maintaining separate SwiftUI, WinUI 3 and GTK4 UIs. Racket owns shared domain logic; native hosts own rendering and OS interaction. For a shared HTML/CSS interface, evaluate Glaze instead.

当第一方原生交互值得维护 SwiftUI、WinUI 3、GTK4 三份界面时,选择 Rivet。共享领域逻辑归 Racket,渲染与系统交互归原生宿主。需要共享 HTML/CSS 界面时可评估 Glaze。

Racket CS 9.0+ and the target platform’s native toolchain. Desktop delivery has explicit capability/acceptance classes; mobile runtime or companion foundations are not a generated, signed and packaged app workflow.

需要 Racket CS 9.0+ 和目标平台原生工具链。桌面交付有明确能力与验收分级;移动运行时或伴随端基础不等于已生成、签名和打包的应用工作流。

Run inspect and doctor in the generated project, complete one backend mutation and observe its persisted result in the packaged native app. Keep one product interaction contract across hosts and adapt shortcuts, focus and window behavior to each OS. A unit test or screenshot alone does not establish product parity.

在生成项目内运行 inspect 和 doctor,完成一个后端修改,并在打包原生应用中观察持久化结果。跨宿主保持一个产品交互契约,快捷键、焦点和窗口行为遵循各系统习惯。单元测试或截图本身不能证明产品一致性。