---
url: https://native-shell.com/docs/comparison
description: "The ways a mobile client can show UI that arrives after release — web views, server-driven UI, mini-program containers, over-the-air updates of cross-platform frameworks — compared with nsh."
---

# Comparing approaches

A mobile client 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. 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.

## 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** | UIKit and Android views | 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

- **Native, not a web page.** 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](https://native-shell.com/docs.md#why-native-shell-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](https://native-shell.com/docs/sandbox-and-capabilities.md)).
- **Embedded, not adopted.** The app stays native and keeps its toolchain; nsh is a view placed where a module should appear ([iOS](https://native-shell.com/docs/embedding-ios.md), [Android](https://native-shell.com/docs/embedding-android.md)).

## 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.

## See also

- [Introduction](https://native-shell.com/docs.md): why nsh exists and what it is designed for.
- [Architecture](https://native-shell.com/docs/architecture.md): what runs where inside nsh.