AppLess: a React Native demo that generates every screen with OUI-1

The problem AppLess picks, and who it is aimed at

Most app stores solve distribution. AppLess asks a different question: what if there were nothing to distribute? The README frames it as a phone with no apps, no menus and no home screen of icons. You ask for a weather dashboard, a restaurant list with live search, a booking form or a chat thread, and the screen is generated on the spot. Tapping anything generates the next screen, prefetched so it appears quickly.

The audience is narrow and technical. This is a TypeScript Expo project pinned to Expo SDK 54 and React Native 0.81, built on OpenUI, the standard the authors also maintain. It is for engineers who want to study generative UI end to end: prompt construction, streaming, rendering, prefetch and tool calls. The README is explicit that AppLess is an experiment with no real integrations behind it. Screen content can be grounded in real data when optional tools are enabled, but every action is simulated. A booking form that says the flight is booked reflects no real state.

One contract, a generated prompt, and openui-lang in between

The architecture is stated as a flow: ui/contract.tsx, then a generated system prompt, then OUI-1 served by vLLM, then openui-lang, then the react-lang renderer, then native UI. The interesting part is the first step. The contract file is the single source of truth for every component the model may use: its name, its props and a description. That contract generates the system prompt, so the model's vocabulary and the renderer's vocabulary cannot drift apart. Add a component to the contract and the prompt changes with it.

The model does not return JSON or hand-written screens. It writes openui-lang, described as a compact streaming-first UI language. The OpenUI Renderer parses that language incrementally and paints real native components while tokens are still arriving. Two design systems implement the same contract, so an identical generated screen becomes Cupertino on iOS and Material 3 on Android with no change to the prompt. Prefetch is the speculative layer: the app generates likely next screens ahead of a tap, controlled by EXPO_PUBLIC_APPLESS_PREFETCH_LIMIT, which defaults to 1, can be set to 0 to disable, and goes up to 6. That trades extra model requests for faster navigation, which is the honest way to describe it.

Installing AppLess and pointing it at a vLLM server

The repository is cloned and installed like any Expo project. The postinstall step runs patch-package, which the package.json confirms as the postinstall script, so do not skip installation with a flag that disables scripts.

git clone https://github.com/thesysdev/appless.git
cd appless
npm install            # postinstall applies the react-lang patch
npm run ios            # or: npm run android, or npm start for Expo Go

The app does not run the model. Screens come from OUI-1, served with vLLM 0.24 or newer on a GPU host, and the phone connects to that server directly. On the GPU host, the README gives two commands and a script that serves the merged checkpoint as OUI-1 with FP8 weights, a 16,384-token context, four concurrent sequences and the gemma4 tool-call parser.

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

The README points to the model card for hardware requirements and notes that FP8 weights occupy about 25.8 GiB plus runtime and cache memory. That is the first real constraint you will hit.

Configuration lives in .env.local, copied from .env.example. The base URL must be reachable from the device, not from your laptop.

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
# EXPO_PUBLIC_EXA_API_KEY=             # enable web_search (Exa)
# EXPO_PUBLIC_UNSPLASH_ACCESS_KEY=     # semantic photos (else LoremFlickr)

Replace the example IP with the GPU host's LAN address or its HTTPS URL. The built-in defaults target localhost:8000/v1 on the iOS simulator and web, and 10.0.2.2:8000/v1 on the Android emulator. On a real phone, localhost is the phone itself, so the default will not work there. Restart Expo after changing environment values. If the server rejects the context length, the app retries after dropping the oldest complete ancestor exchange while preserving the current request and tool results; if those alone exceed the limit, it reports an actionable error.

Authentication, keys and what ships inside the bundle

A local vLLM server without authentication opens immediately. For a protected endpoint, start the server with an API key and tell the app to prompt for it.

bash scripts/serve-oui.sh --api-key your-server-key
EXPO_PUBLIC_MODEL_AUTH_REQUIRED=1

Entered keys are stored per endpoint in Keychain or Keystore, and in localStorage on web. The README notes that old Cerebras credentials are not reused, which suggests the project previously pointed at a hosted provider. For development, EXPO_PUBLIC_MODEL_API_KEY skips entry, but the README warns that all EXPO_PUBLIC_* values are embedded in the app bundle. That is not a subtle caveat; it is the reason remote deployments should put vLLM behind authenticated HTTPS access rather than trusting a key shipped inside a mobile binary. The same applies to the optional Exa and Unsplash keys: convenient for a demo, wrong for anything public.

Where AppLess is the wrong tool

The README carries a warning block, and it is worth taking literally. AppLess is an experiment by the OpenUI creators with no real integrations behind it. Screen content is generated by the model, so without the optional web and image tools it is plausible fiction. With EXPO_PUBLIC_EXA_API_KEY set, the model can call web_search for real places, prices and news; without it, the model invents data. Photos come from Unsplash when EXPO_PUBLIC_UNSPLASH_ACCESS_KEY is set, and from LoremFlickr otherwise, which is a placeholder service.

The actions are always simulated. Order placed, flight booked, payment sent and live health stats do nothing and reflect no real state. If your goal is a working replacement for the apps on your phone, this is not it, and the README says as much until someone makes it real. A second failure mode is operational rather than conceptual: the app is useless without a reachable vLLM endpoint. A phone on cellular cannot reach a LAN address, and cleartext HTTP or local-network access may require platform-specific build permissions. A standalone native build should use an HTTPS endpoint, and web builds need the server to allow their origin.

How it differs from a JSON-schema function-calling stack

The obvious alternative is the pattern most teams already run: ask a model for a JSON payload that matches a schema, validate it with a library such as zod (already a dependency here), then render from a fixed component map. That approach is easier to test and easier to log, because the intermediate representation is data you can inspect and store. Its weakness is granularity. A JSON document usually arrives complete, so the UI waits for the full object before painting anything.

AppLess inverts that. The model emits openui-lang, and the renderer parses it incrementally, so components appear while the response is still streaming. The cost is a second language to learn and a renderer that must tolerate partial input. The prefetch layer has no direct equivalent in the JSON approach either: generating likely next screens ahead of a tap is a bet on user behaviour that costs model requests, which is why the limit is configurable and defaults to a modest 1. If your screens are few and stable, a schema-driven renderer will be cheaper to operate. If the screen itself is the product, the streaming DSL is the more interesting bet.

Maintenance, licence and the upgrade cost you should price in

The repository is not archived, and the last push was on 2026-09-16, so it is being worked on right now. That cuts both ways for adopters: there are no releases retrieved, and the version in package.json is 1.0.0, so there is no tagged upgrade path to follow. The dependency surface is the real maintenance cost. Expo SDK 54 is pinned to match the Expo Go build on the stores, and the README tells you to reconcile a mismatch with npx expo install expo@^<version> && npx expo install --fix. React Native is pinned at 0.81.5 and react at 19.1.0, so an Expo upgrade is a coordinated move across the app, not a patch. The @openuidev/react-lang dependency sits at 0.1.5, a pre-1.0 renderer that the project patches through patch-package on install; a patch that fails to apply after a dependency bump is a realistic breakage point.

The server side has its own upgrade cost. vLLM 0.24 or newer is required, and the serve script encodes specific choices: FP8 weights, a 16,384-token context, four concurrent sequences and the gemma4 tool-call parser. VLLM_HOST, VLLM_PORT, VLLM_MAX_MODEL_LEN and VLLM_MAX_NUM_SEQS are overridable, and extra arguments are forwarded to vllm serve. The licence is MIT, and the LICENSE file is at the repository root, which is permissive for reuse; the model weights are a separate artefact with their own card, so check that separately before you build on them. None of this is legal advice.

Editorial conclusion

Adopt AppLess if you want to see how a single contract, a streaming DSL and native renderers fit together, or if you plan to fork it and wire real backends into the simulated actions. Do not adopt it as a working replacement for phone apps: the README states that orders, bookings and payments do nothing. Before committing, verify that you can serve OUI-1 with vLLM 0.24 or newer on a GPU host, because the Expo app has no bundled model and will not generate anything without a reachable endpoint.

Frequently asked questions

Official sources

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