longbridge/nsh

NSH wants you to write a screen once and have it show up with genuine native widgets on phones, desktops and the browser. It is early (first release 0.1.1), so the sensible way to read this review is as a map of the design and its boundaries, not an endorsement for shipping.

The problem

Cross-platform UI usually forces a choice: write native code per platform, or accept a webview-rendered UI that looks and behaves unlike the host. You want one set of components, state and layout rules, but menus that behave like desktop popups, sheets that slide like phone dialogs, and text input that uses the platform's own keyboard. NSH changes that step by rendering your components through UIKit on iOS, Win32 on Windows, GTK 4 on Linux, and HTML on the web, while sharing a reactive engine and flexbox/grid layout across them. The result is one codebase that packages as a standalone app or embeds into an existing native app.

What's different

The interesting mechanism is the split between authoring and rendering. You can write the whole app in Rust, screens in TSX, or mix them so TSX imports Rust components. On the TSX side the engine loads modules at run time, which the authors position for plugins and AI-generated UI, delivered as signed packages and run in a host-configured sandbox. A single Rust-built nsh CLI covers init, run, hot updates and packaging.

Two trade-offs stand out. First, the design is deliberately unstyled: nsh/base supplies behavior and accessible structure, but colors, typography, spacing and motion are the app's responsibility, with Tailwind classes and shadcn-derived theme tokens on the TSX side. That buys app-owned looks at the cost of assembling your own component library. Second, each desktop uses its own backend, so behavior can differ across AppKit, Win32 and GTK 4; the GPUI backend is an additional target rather than a replacement. Runtime-loaded, signed TSX packages are an architectural capability described in the README, not something this review can vouch for in practice.

Who should try it

Good fit: a team already comfortable in Rust and TypeScript, building an app that must appear native on several platforms, and willing to own its visual design through primitives. The "embed in an existing native app" examples are the clearest reason to choose it over a from-scratch toolkit. Poor fit: someone who wants batteries-included widgets and a settled API. At version 0.1.1 the framework is explicitly early, and the unstyled base means a visually finished app requires significant design work before the framework's value shows up.

Requirements and limitations

Platform floors are concrete: iOS 15+, Android 9 (API 28)+, macOS 14+, Windows 10 1809+, GTK 4.14+ on Linux, and Vulkan for GPUI on Linux. Those floors rule out older devices and some long-lived Linux desktops, and building for iOS or Android still needs Xcode or the Android SDK. The Rust path needs both nsh and Rust, while the TSX path needs only nsh for authoring; installers exist for macOS/Linux via script, Homebrew, and Windows via PowerShell.

Ongoing upkeep is the bigger question. The README documents hot updates for TSX but says Rust changes require rebuild and restart, and the install script can update the CLI and the source checkout kept at ~/.nsh/source. Whether the component behavior and theming APIs stay stable enough to avoid frequent rewrites is unknown from the README alone; check the installation and platform notes and the goals document before committing.

HotRepo's take

HotRepo recorded 614 total stars on the NEW-REPOSITORY board (rust, #14) on 2026-10-25, with coverage spanning only 2026-10-24 to 2026-10-25. That is a dated snapshot, not a growth curve, and persistence cannot be judged from two observation dates on a ten-day-old repository. Treat the design as worth reading and the API as worth verifying: the specific thing to check is whether the unstyled nsh/base primitives and theme tokens give you enough of a component foundation for the screens you actually need.