// the take
Hyperview is a hypermedia framework for React Native: instead of shipping UI logic in the app, the server returns HXML (a custom XML vocabulary) describing screens, and the client renders and navigates based on that XML, HTMX-style but for native mobile. It's for teams that want to change app layout, content, and behavior via backend deploys instead of app store releases, built and run in production at Instawork.
The architecture is a real idea, not a wrapper: pushing the hypermedia constraint onto mobile means any backend that can emit XML (Django, Rails, Node, even static files) can drive the app, with no custom API layer to version. The client package itself is lean, just xmldom, lodash, tiny-emitter, and url-parse as hard dependencies, so it drops into an existing React Native app as a library rather than demanding a full rewrite. It's dogfooded in a real product at Instawork with CI (CircleCI) and recent commits, not an abandoned research project.
Every interaction that isn't covered by the built-in behavior vocabulary means writing a custom native "behavior" extension, so nontrivial client-side logic just moves the complexity into bespoke code you still have to maintain. The model assumes a live, fast connection: screens are fetched as needed, and there's no first-class offline or poor-connectivity story, which is a common failure mode for native apps that this doesn't really solve. The ecosystem is small and essentially single-vendor; 1.7k stars but the project, docs, and conventions are driven almost entirely by Instawork, and writing HXML has none of the tooling (autocomplete, type checking, linting) you'd get authoring normal RN/JSX. Peer dependencies are tightly version-pinned (specific React Navigation, Expo, RN, gesture-handler versions), so dropping it into an existing app with a different stack can mean real dependency wrangling before you write a line of HXML.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →