AppLess: Live-Generated Native UI Without a Single Installed App

What AppLess Demonstrates and Who Should Run It

AppLess is a demonstration built by the creators of OpenUI to show what a generative-UI operating system could feel like in practice. There are no installed apps, no home screen, and no menus to learn. Open the Expo app, type a request, and the screen for it appears live, generated by a language model.

The target audience is developers and researchers exploring the OpenUI standard. The README is explicit that this is a push on the boundaries of generative UI with no real integrations behind it. The actions behind every screen, whether placing an order, booking a flight, or reading a health statistic, are always simulated. Nothing is wired to a real service.

The OpenUI Stack: Contract, DSL, and Dual-Platform Rendering

The architecture centers on a single file: `ui/contract.tsx`. That file declares every UI component the model is permitted to use, including its name, props, and a short description. The contract generates the system prompt automatically, so OUI-1 always works from the exact vocabulary the renderer can handle. When the contract changes, the system prompt changes with it.

The model does not return JSON or pre-built screens. It writes openui-lang, a compact streaming-first DSL defined by the OpenUI standard. As tokens arrive, the OpenUI renderer parses openui-lang incrementally and paints real native components live, before the response has finished. Two separate design systems implement the same contract: Cupertino components appear on iOS and Material 3 components appear on Android, with no change to the prompt. The platform adaptation is automatic.

When optional tools are enabled, the model can call a `web_search` function mid-stream using the Exa service, grounding generated content in real search results with sources cited. Images work as semantic queries the app resolves on-device. Without those tool keys, the README states that screen content is plausible fiction generated by the model with no connection to real data.

Setting Up the OUI-1 Server and Running the App

OUI-1 is the model that drives AppLess. It is hosted on HuggingFace and served with vLLM version 0.24 or newer on a GPU host. The phone connects directly to that server; the model does not run inside the Expo app.

To start the app, clone the repository and install dependencies:

git clone https://github.com/thesysdev/appless.git
cd appless
npm install
npm run ios

The `npm install` step runs a postinstall script that applies a patch to `react-lang`. Use `npm run android` or `npm start` for other targets.

On the GPU host, serve OUI-1 with the included script:

pip install "vllm>=0.24"
bash scripts/serve-oui.sh

The FP8 weights occupy roughly 25.8 GiB plus runtime and cache memory. The script sets a 16,384-token context, four concurrent sequences, and the `gemma4` tool-call parser. Full hardware requirements are in the model card on HuggingFace.

Copy `.env.example` to `.env.local` and set the server address the app can reach:

EXPO_PUBLIC_MODEL_BASE_URL=http://192.168.1.100:8000/v1
EXPO_PUBLIC_APPLESS_MODEL=OUI-1
EXPO_PUBLIC_APPLESS_MAX_TOKENS=4096
EXPO_PUBLIC_APPLESS_PREFETCH_LIMIT=1

Use the GPU host's LAN IP for a real phone. The default of `localhost:8000/v1` applies for an iOS simulator or web build; `10.0.2.2:8000/v1` for an Android emulator. Restart Expo after changing any `EXPO_PUBLIC_*` value, as these are embedded in the bundle at build time.

Prefetching, Context Management, and 256-Token Streaming

OUI-1 streams in committed 256-token blocks and ignores the request temperature and seed parameters, so the client sends neither. The prefetch system generates likely next screens before the user taps: `EXPO_PUBLIC_APPLESS_PREFETCH_LIMIT=1` queues one destination per screen by default, `0` disables prefetch entirely, and the maximum is 6. Raising the limit trades extra model requests for faster-feeling navigation.

Context management is automatic. If the server rejects the request because the accumulated context exceeds the configured length, the app drops the oldest complete ancestor exchange and retries, preserving the current request and any tool results. If the current request alone exceeds the context limit, the app reports an actionable error rather than failing silently.

The app is pinned to Expo SDK 54 to match the Expo Go builds available on the App Store and Play Store. If Expo Go reports a different SDK version, the README advises running `npx expo install expo@^<version> && npx expo install --fix` to align them.

The Simulation Boundary: Actions That Do Nothing

Every action in AppLess is simulated. An order confirmation, a flight booking, a payment receipt, a live health metric: none of these reflect real state or communicate with any real service. The README documents this limitation directly. The screens look like real application flows, and tapping a button generates the next screen, but nothing is wired up.

Content grounding depends on optional API keys. Without `EXPO_PUBLIC_EXA_API_KEY`, web search is unavailable and the model generates plausible-sounding data with no connection to the real world. Without `EXPO_PUBLIC_UNSPLASH_ACCESS_KEY`, images come from LoremFlickr rather than a semantic photo source.

For servers with authentication, adding `--api-key your-server-key` to the vLLM serve command and setting `EXPO_PUBLIC_MODEL_AUTH_REQUIRED=1` prompts for the key in the app on first launch. Entered keys are stored per endpoint in the device Keychain or Keystore, or in localStorage on web. All `EXPO_PUBLIC_*` values are bundled into the app, so development keys should not carry production credentials.

AppLess Compared to Conventional App Frameworks

A traditional app ships a fixed set of screens. Navigation is deterministic. AppLess generates every screen at runtime from a natural-language prompt; there are no predefined layouts, no hard-coded flows, and no SDK calls to real services.

The tradeoff is structural. A traditional app can place an order, confirm a payment, or read a sensor because it holds real integrations. AppLess can display a screen that resembles any of those flows but cannot act on them. The approach also requires a running GPU server that the device can reach over the network. A traditional app works offline for its built-in screens.

The closest comparison in terms of approach is a low-code tool like React Native combined with a form-builder backend. That combination also generates UI from a data description, but the description is hand-authored and the actions are real. AppLess generates the description live from a prompt; React Native renders it as the same native primitives, but through a different runtime path.

For a developer testing how openui-lang handles edge cases, or exploring how a generative OS might behave under different prompt styles, AppLess is the fastest available test bed. For anyone building something that needs to do anything after the user taps a button, it is not the right starting point.

Editorial conclusion

AppLess belongs on the machine of a developer or researcher who wants to see what OpenUI and generative UI look like running on a real phone. It is not suitable for production use, and the simulation boundary is hard: no order, payment, or health stat reflects any real state. Before starting, verify your GPU host can supply the roughly 25.8 GiB the OUI-1 FP8 checkpoint requires, and read the vLLM security documentation before exposing the server on a network.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. thesysdev/appless on GitHub