react-native-desktop-qt: a React Native desktop port that stopped

The first line of the README is the whole story

The repository opens with three warning emoji and a single line: React Native Desktop project support stopped.

That is not a caveat, it is the status of the project. The rest of the README is a documentation site for something that is no longer being worked on, and everything else in the file is written in the present tense as though it were still live, which is how a lot of archived documentation reads.

The dates confirm it. The last push to the repository was on 2026-10-06, but the published releases stop in 2020, with v0.60.6_1 fixing a linking module on 2020-05-29, v0.60.6 for compatibility with React Native 0.60.6 on 2020-05-13, and v0.59.9 for React Native 0.59.9 in April 2020. The package version in the manifest is still 0.60.6, and the dev dependencies pin React 16.8.6 and React Native 0.60.6.

So there is a gap of about six years between the last release and the last commit. The recent commit is likely maintenance of the repository itself rather than of the port, and the version numbers in the releases track React Native releases exactly, which is the tell that this was a version-locked port rather than an independent one.

The project is BSD licensed, the primary language is JavaScript, the default branch is master, and the homepage link points at the status-im react-native-desktop repository rather than this fork.

A Qt port, forked from Canonical

The project is a cross-platform React Native desktop port based on the Qt framework, forked from Canonical, and it supports Linux, checked with Ubuntu 16.04 LTS or later, Mac OS, and Windows.

The interesting engineering is in the directory names, which describe the layers of the port. There is ReactQt/, which is the Qt side of the bridge, and Libraries/ and ReactCommon/, which are the React Native code itself, kept as a fork rather than pulled from upstream. There is RNTester/, which is React Native's own test application, brought along so the port can be checked against the reference implementation. There is local-cli/, metro.config.js, babel.config.js, and js-executor.js at the top level, and a CMakeLists.txt for the C++ and Qt build.

The Examples/ directory is the clearest evidence of the scope. ActivityIndicator, Alerts, Button, Fetch, FlatList, Image, Modal, ScrollView, TicTacToe, TouchableEvents, and Transform. That is a set of UI primitives and a couple of small applications, and its shape tells you the port targeted the rendering and event handling layers rather than the whole React Native surface. There is an Example.qml.in template, which is the QML file each example is generated from, and a run-example.sh.in script.

The documentation directory has a page for the list of supported React Native components and APIs, which is the page that tells you what actually works, and a separate page for third-party react-native modules support, since native modules are where a port like this falls apart.

The internals, and why the documentation has separate pages for them

The contributing section links four documents that describe how the port works, and their titles are the architecture.

There is a page on how react-native-desktop works internally, one on the Yoga layout engine in react-native-desktop, one on merging React Native, and an environment setup guide for contributors.

Yoga is the one that matters most for understanding the port. React Native computes layout in JavaScript using Yoga, and the results are then handed to a native renderer. In a Qt port, those computed layout values have to be applied to Qt items, which means the port has to bridge a Yoga layout tree into a QML item tree. That is a nontrivial amount of work, and it is the kind of work that is invisible until it breaks, which is why a page about it exists.

The merging React Native page is about the other half of the problem. Because Libraries/ and ReactCommon/ are a fork, every React Native release has to be merged in by hand, and that is a recurring, manual, conflict-prone chore. The release naming scheme reflects it, since each release is named after the React Native version it matches.

The debugging documentation is also worth noting. To access the In-App Developer Menu you press CTRL+R, or Command+R on a Mac, and the menu is available in Debug builds. There is a page on inspecting the JS code and another on using GammaRay for inspecting the Qt internals, which is a KDE tool for introspecting a running Qt application. The fact that the project documents how to look inside its own native layer says something about how hard that layer is to debug.

ClojureScript, and the Re-Natal fork

One feature in the README is worth singling out, because it is unusual and it connects the port to a specific ecosystem.

There is ClojureScript React Native apps support, through a Re-Natal fork extended with desktop platform support. Re-Natal is the React Native tooling for ClojureScript, and the fork adds the desktop platform to it.

That is a small line in a README but a meaningful statement about the project. Most desktop React Native ports target JavaScript and TypeScript developers, and the ClojureScript audience is smaller and more opinionated. Extending an existing ClojureScript toolchain rather than asking people to set up a new one is the difference between a port that can be used and a port that can be demonstrated.

It also suggests the origin of the fork. The repository metadata credits Volodymyr Kozieiev as the author and the bugs and homepage URLs point at the vkjr GitHub account, which is the same person behind the re-natal fork. The fork is a personal contribution to a project that Canonical built and then stopped maintaining.

That history explains the shape of the repository. The top level still has the Canonical-style layout with a .circleci/ directory, a .travis.yml that is no longer Travis CI, and a .dependabot/ directory for dependency updates. It is a project that was set up well, documented carefully, and then handed over.

Editorial conclusion

Adopt this repository only as a reference implementation if you are studying how a React Native renderer can be hosted on Qt, since the project is unmaintained. Do not adopt it as a platform for new work, because the README states that project support stopped and the last release was in 2020. Verify first that the React Native version your application uses is close to the 0.60.6 this port targets, since the rendering layer is a fork.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. status-im/react-native-desktop-qt on GitHub