AppLess says its own buttons do nothing, and puts the warning above the demo

The warning about simulated actions comes before the demo

The honesty here is structural rather than buried. A callout placed above the demo section states that AppLess is an experiment by the creators of the interface standard it is built on, that it has no real integrations behind it, and that the screen content is generated by the model: with the optional web and image tools enabled it can be grounded in real data such as real places, prices, news and photos, and without them it is plausible fiction. Then the sentence that matters most: the actions are always simulated. Order placed, flight booked, payment sent and live health statistics do nothing and reflect no real state, because nothing is wired up. The callout closes by saying this is a glimpse of what a generative interface operating system could feel like, not a working replacement for your apps. A reader who skips the callout will still believe they can book a flight, so the placement is doing as much work as the wording.

The model does not run on the phone, it runs on a GPU host

The quick start is a two-machine exercise and the readme is direct about it. Screens are generated by the model, served with a recent vLLM release on a GPU host, and the phone connects directly to that server; the model does not run inside the Expo application. The client side is a clone and an install:

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 server side is a pip install of vLLM and a shell script that serves the merged checkpoint. The configuration file makes the split explicit with a base URL, a model name, a token budget and a prefetch limit. The defaults are the part that will bite a first run: the built-in addresses target the development host from a simulator or the Android emulator's host alias, and on a real phone the word localhost means the phone itself. A physical device needs the host's LAN address or an HTTPS URL.

Every setting is an EXPO_PUBLIC variable, so the bundle carries them

The environment file is commented at the top with the fact that all such values are embedded in the app bundle. That single mechanism explains most of the security surface. The model base URL, the model name, the token budget and the prefetch limit are all in there, and so are the optional keys for the search tool and the photo service, and a flag that opts out of anonymous run analytics. The readme handles authentication carefully in a way that deserves credit and a caveat in the same breath. A local server without a key opens immediately, and for a protected endpoint you can start the serving script with a key argument and set a flag that makes the app prompt for it, with entered keys stored per endpoint in the platform keystore, and a storage fallback on web. The caveat is the development shortcut: supplying a key through the public variable skips entry entirely and puts that key in the shipped bundle, which the readme says in as many words. So the only safe path for a real key is the interactive prompt.

One contract file generates the prompt the model is given

The architecture is a chain of six stages and the interesting link is the first one. A single contract file is the source of truth for every component the model can use, recording its name, its props and a description. That contract generates the system prompt, so the model's vocabulary is derived from the renderer's capabilities rather than maintained alongside them, which is the failure mode this design removes. There is a script whose only job is to embed the generated prompt, which means the prompt is a build artefact you can inspect and diff rather than a string buried in source. The model streams a compact interface language back, an incremental parser paints native components while tokens are still arriving, and two design systems implement the one contract, so the same generated screen renders as one platform's native style on iOS and the other's on Android with no change to the prompt. The point of a contract like this is that adding a component is a one-line change that the model learns about automatically.

Tapping a row prefetches the next screen before you ask for it

Navigation is speculative and the knob is exposed. Tapping a row, a chip or a button streams the next screen, and separately the app generates likely destinations ahead of the tap so navigation feels instant. One environment variable controls how many destinations to generate per screen, with a default of one, zero to disable it and an upper bound of six, and the readme says plainly that this is optional and trades extra model requests for faster navigation. On a single GPU that is a real cost multiplier, and the default of one is a sensible compromise rather than a free win. Two other behaviours are worth knowing. The model ignores request temperature and seed, so the client sends neither, and it streams in committed blocks of 256 tokens, which means partial output exists before the response finishes. When the server rejects the context length, the app retries after dropping the oldest complete exchange, keeping the current request and the tool results, and reports an actionable error if those alone do not fit.

Images are semantic queries the device resolves, not model output

The tool story is two optional integrations and a fallback for each. When a screen needs live facts the model calls a web search tool mid-stream and composes the screen from the results with sources cited, and the readme is explicit that without the key for that service the model invents the data instead. Images work differently and more cleanly: they are referenced as semantic queries that the app resolves on the device, so the model describes what it wants rather than emitting a picture, and the resolution happens locally. With a photo service key you get real photographs and without one you get a placeholder image service, which the environment file names. So the same generated screen is either grounded or decorative depending on two unset variables, and the difference is invisible in the output unless you know to look for citations. The star citation for images sits in the demo section rather than in a tool list, which is a reasonable place for it and one more reason to read the callout first.

The manifest patches a dependency on every install and pins an Expo SDK

Two build details explain most of the friction in the quick start. The install command applies a patch after dependencies are installed, and the manifest runs it as the postinstall step, with a patches directory at the repository root. A patched dependency is a maintenance commitment rather than a convenience, because an upstream release can conflict with the patch and there is no version range protecting you. The second is the Expo SDK, which the readme says is pinned to match the Expo Go build published in the app stores, with a command to reinstall at a matching version and fix the rest of the dependencies if your Expo Go reports a different SDK. Pinning to a store build is the right call for testing on a device, and it is also the reason a dependency update is a coordinated change rather than a version bump. The manifest is private, so there is no published package, and the test setup carries a per-package transform allowlist that any new native dependency has to be added to.

Editorial conclusion

Read AppLess as a demonstration of a rendering approach rather than as a phone operating system, because that is what the project says it is: an experiment by the creators of the underlying interface standard, with a warning that its actions are always simulated and its content is fiction unless you configure two third-party keys. The architecture is the part worth taking. A single contract file describing every component the model may use generates the system prompt, so the model's vocabulary and the renderer's capabilities cannot drift apart, and one contract renders through two design systems without a prompt change. Two things to know before you build on it. The model does not run on the device, it runs on a GPU host under vLLM with FP8 weights, which is why the quick start is a two-machine exercise. And every setting is an EXPO_PUBLIC variable, which Expo embeds in the bundle, so the development key path puts a server credential in the shipped app and only the interactive prompt with device storage is safe for anything real. The last commit on the default branch main is dated 16 September 2026 and there are no releases.

Frequently asked questions

Official sources

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