Docs
Comparing approaches
An app that wants UI it did not ship with — answers generated by a model, features from partners or other teams, screens that change without a release — has a handful of established options, on phones and desktops alike. They differ in what draws the UI, what the delivered code may do, and how much of the app has to change to host them. This page compares them with NSH, and then compares NSH with the cross-platform frameworks used to write whole apps.
#The options
| What draws it | What it can express | Confinement | Fit for generated UI | Cost to the host app | |
|---|---|---|---|---|---|
| Web view (H5) | A browser engine | Anything HTML, CSS and JS can | Same-origin rules; native access through a hand-written bridge | Models write HTML well; the result looks and behaves like a web page | A browser engine per view; a bridge to maintain |
| Server-driven UI | The app’s own native views | Only the components and actions the app built in, described in JSON | Total: the schema is the limit | Easy to generate, little to express: no local state or logic beyond what the schema provides | A renderer for every component and its versions, in each app |
| Mini-program containers | Usually a web engine with a proprietary layer | A platform-specific framework and API | The container’s permission model | Proprietary dialect, less known to models | A large container SDK |
| Over-the-air updates of a cross-platform app (React Native with a code-push service, for example) | That framework’s renderer | The whole framework | None: updates are trusted app code | Code generated per request is not what these updates are for | The app has to be written in that framework |
| NSH | The platform’s own UI: UIKit, Android views, AppKit, GTK 4, Win32 with Direct2D | Components with state, logic, animation and layout; host-registered native views | Signed packages, a VM per view with host-set limits, capabilities granted per view | Designed for it: one TSX module, typed API, headless checks | One view and a library in an existing native app |
#How NSH differs
- The platform’s own UI. A module is made of the platform’s views, so text selection and its menu, input methods, accessibility and scrolling are the system’s own — the same reason NSH exists next to GPUI Shell.
- More than a schema. Server-driven UI only recombines what the app already ships. An NSH module has its own state, logic, animations and layout, so a model can produce an interface the app’s developers never anticipated.
- Confined by the host. Delivered code is untrusted. NSH checks signatures and revocations before running anything, gives each view its own VM with memory, call-time and node limits, and lets the host decide which network hosts, web pages and system settings a module may reach (Sandbox and capabilities).
- Embedded, not adopted. The app stays native and keeps its toolchain; NSH is a view placed where a module should appear (Platforms).
- One module, every platform. The same bundle runs on iOS, Android, macOS, Windows and Linux, each time with that platform’s own UI (Platforms).
#Cross-platform frameworks
NSH is designed for modules inside native apps, but the same modules can be packaged as whole apps for every platform, so it is natural to compare it with the frameworks people write cross-platform apps in. The comparison is about how each draws and where it runs, not about maturity: these frameworks have large ecosystems that NSH does not have.
| What draws it | Platforms | App code | Code delivered after release | |
|---|---|---|---|---|
| React Native | The platform’s views on iOS and Android; desktops through separate projects | iOS, Android; Windows and macOS out of tree | JavaScript or TypeScript, with React | Over-the-air updates of trusted app code |
| Flutter | Its own engine draws every pixel | iOS, Android, macOS, Windows, Linux, web | Dart | Not part of the framework |
| Electron | Chromium, bundled with the app | macOS, Windows, Linux | HTML, CSS, JavaScript | Web content the app loads |
| Tauri | The system’s web view | macOS, Windows, Linux, iOS, Android | HTML, CSS, JavaScript; Rust for the native side | Web content the app loads |
| NSH | The platform’s own UI on each platform | iOS, Android, macOS, Windows, Linux | TSX modules; the runtime and components are Rust | Signed packages, verified and sandboxed per view |
What sets NSH apart:
- Native UI on every platform, not one renderer everywhere. Flutter draws everything itself, and Electron and Tauri show web pages; NSH builds each platform’s own views, so text selection, input methods, accessibility and the system’s look come from the platform.
- Small modules inside native apps. The frameworks above own the whole app. NSH is designed to sit inside an app written with the platform’s own tools, as one view among others, and to run modules the app did not ship with, in a sandbox.
- A light runtime. No browser engine per app or per view; JavaScript only runs the module’s own code, and everything it calls is native Rust.
#When another option fits better
- The UI is a document or an existing web page: a web view shows it as it is.
- The set of screens is fixed and small, and only content and order change: server-driven UI needs no runtime at all.
- The whole app is written in a cross-platform framework already: its own update mechanism ships its code.
- You need a large ecosystem of third-party packages, or a desktop UI kit with desktop controls today: NSH’s components are the mobile set.
#See also
- Introduction: why NSH exists and what it is designed for.
- Architecture: what runs where inside NSH.