# ReNative: one CLI that bootstraps projects across sixteen platform targets

> ReNative is a TypeScript monorepo and CLI, published to NPM as rnv, that wraps React, React Native, NextJS and Electron so a single project can be bootstrapped, developed and deployed to phones, TVs, desktops and wearables. The repository is active, but every tagged release in the recent history is a release candidate rather than a stable version.

**flexn-io/renative** — 🚀🚀🚀 Unified Development Platform for iOS, tvOS, Android, Android TV, Android Wear, Web, Tizen TV, Tizen Watch, Tizen Mobile, LG webOS, macOS/OSX, Windows, KaiOS, FirefoxOS Firefox TV platforms

- Repository: https://github.com/flexn-io/renative
- Website: https://renative.org
- Stars: 1,961 · Forks: 189
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/flexn-io-renative

## The proposition: bootstrap, develop and deploy from one environment

ReNative is described as a unified development platform, and the package description enumerates the targets without hedging: iOS, tvOS, Android, Android TV, Fire TV, Android Wear, web, Tizen TV, Tizen Watch, Tizen Mobile, LG webOS, macOS/OSX, Windows, KaiOS, Linux and Chromecast.

That list is the product. Almost every cross-platform tool stops at phone and desktop, and React Native covers iOS and Android well. The interesting part of this list is the tail: Tizen Watch, webOS, KaiOS, Android Wear, Fire TV.

It supports the front-end frameworks you would expect to bring to such a problem, namely React, React Native, NextJS and Electron. So the shape is: your application source stays in a framework you already know, and ReNative supplies the per-platform build, packaging and deploy path.

The intended user is a team shipping to more than one of those targets, who would otherwise maintain several build configurations, several template sets and several CI pipelines by hand. A single platform team gains nothing from this.

## Getting started is two commands

The CLI is published to NPM as rnv, and installation is global:

```bash
npm i -g rnv
```

Starting a project is then:

```bash
rnv new
```

That is the entire quick start the README offers, and it is worth noticing how little it says. There is no flag list, no template selection walkthrough and no example command for running a build. The README defers both of those to the documentation site, pointing at the quickstart page and the introduction page, and it also states that the documentation source lives in a separate repository, flexn-io/renative-docs.

That split has a consequence for anyone evaluating the project offline: the README in this repository tells you what ReNative is and how to install it, and almost nothing about how it works. If your decision depends on understanding the template system or the engine resolution, that understanding has to come from renative.org rather than from the code you can read here.

What the repository does show is the shape of the codebase. This is a lerna monorepo with a packages/ directory, a yarn.lock, a jest.config.js and a spec/ directory for tests, plus __mocks__/ for test doubles. TypeScript is configured through tsconfig files, linting through .eslintrc.js and .eslintignore, formatting through .prettierrc.js, and there is a .husky/ directory for git hooks. buildHooks/ at the root suggests the per-platform build steps are implemented as hooks the CLI invokes, which is a reasonable design for something that has to extend native toolchains.

## Reading the version numbers honestly

The release history is the most informative thing in the repository metadata, and it needs reading carefully.

The three most recent releases are 1.10.0-rc.0 on 2025-01-13, 1.10.0-rc.1 on 2025-03-19 and 1.10.0-rc.3 on 2025-03-31. Every one of them is a release candidate. There is no 1.10.0 final among them, and package.json still reads version 1.10.0-rc.1, which is behind the newest tag.

Set that against the last push, which was on 2026-10-06, with the repository not archived. So the working tree is being maintained while the tagged line is a release candidate that stopped moving in March 2025. Both statements are true and they point in different directions.

For an adopter, the practical question is what you actually install. Installing rnv globally gives you whatever is latest on NPM, and with a candidate line that is a decision about churn rather than about stability. Pinning an explicit version is the more defensible choice, and if you pin a candidate you should accept that it may never become a stable tag.

A second question is where the monorepo version and the published package version diverge. The root package is named @flexn/renative-monorepo, so the CLI package rnv and the monorepo root are versioned separately in practice, and the README's install command targets the rnv package, not this repository's root package.

## Where the abstraction costs you

The first limitation is the template model. When a CLI generates your project structure, that structure becomes the contract between you and the tool. Debugging a native build failure means reading a generated config you did not write, and when you need to step outside what the template supports, you are editing something the next rnv run may overwrite. That risk is inherent to any bootstrap tool and it is larger here, because the number of platform templates is the product.

The second is dependency on per-platform toolchains the CLI does not supply. The listed targets span several platform toolchains, and each has its own licensing, version and machine requirements. A platform you cannot install locally is a platform you cannot debug locally, and the abstraction does not change that.

The third is the release candidate situation described above. Depending on a CLI for your build path means depending on its maintenance, and a repository whose newest tag is a candidate from over a year and a half before the last push is a maintenance question, not a settled fact.

The fourth is documentation location. The README here is thin by design, with the substance in renative.org and its source in another repository. If you are evaluating under time pressure, that is friction before you have installed anything.

None of this makes the tool wrong. It makes the adoption decision one about how much of your build you are willing to hand to a layer above the framework.

## How React Native and Expo differ

The direct comparison is React Native with Expo, and the difference in approach is about who owns the native project files.

ReNative says it supports mobile, web, TV, desktop, console and wearable platforms through a single development environment.

The second comparison is writing the build configuration yourself. Multiple platform targets handled by hand can mean multiple template sets and CI configurations, which is exactly the cost ReNative exists to remove. For a team that genuinely needs Tizen Watch and webOS, that saving is large and there is no shortcut.

The third is the middle option: use React Native directly for the phone targets and hand-write build steps only for the awkward platforms. That gets you a familiar native workflow on iOS and Android, and leaves you maintaining the TV and wearable builds yourself. It is more work than ReNative and less opaque than ReNative.

The deciding question is how many of the listed targets you actually need. One or two means the alternatives win. Six means the tool has paid for itself.

## Licence, community and what to verify

ReNative is MIT licensed, with a LICENSE file at the repository root and the MIT declaration in package.json, along with an OpenCollective badge. This is a permissive grant and this is a licence note rather than legal advice.

The project carries the conventional files you would expect from a maintained open source repository: CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md, FUNDING.yml and a .github/ directory. FUNDING.yml plus the OpenCollective backers section in the README indicate the project takes money, which is worth knowing as context rather than as a technical fact.

Two core maintainers are named, Pavel Jacko and Mihai Blaga, with Pavel Jacko also listed as the package author. Community discussion happens on GitHub Discussions rather than a chat server or a forum, which is a smaller surface than many projects of this age maintain.

Before installing, check four things. Confirm the exact version you are pinning and whether it is a candidate, since all three recent tags are. Read the quickstart at renative.org rather than assuming the two README commands are the whole workflow. Check which of your required targets have the native SDKs installed on the machines that will run the build. And check whether your framework choice is one of the four named, React, React Native, NextJS or Electron, since the framework list is explicit in the description.

## Conclusion

Use ReNative if your product genuinely spans several of the platforms its package description names, particularly TV and wearable targets, and if you are willing to make rnv part of your build path rather than treating it as scaffolding you run once. Verify first which release you are installing: the three most recent tags are 1.10.0-rc.0, 1.10.0-rc.1 and 1.10.0-rc.3 from early 2025, package.json reads 1.10.0-rc.1, and there is no 1.x stable tag in that list, so pin deliberately rather than tracking the newest tag.

## FAQ

### How do I install the ReNative CLI and start a project?

Install the CLI globally with npm i -g rnv, then run rnv new to create a new project. The README links to renative.org for the quickstart and full documentation, and the documentation source lives in the separate flexn-io/renative-docs repository.

### Which platforms does ReNative support?

The package description lists iOS, tvOS, Android, Android TV, Fire TV, Android Wear, web, Tizen TV, Tizen Watch, Tizen Mobile, LG webOS, macOS/OSX, Windows, KaiOS, Linux and Chromecast. It supports React, React Native, NextJS and Electron as front-end frameworks.

### Are there stable releases of ReNative?

The three most recent tags are 1.10.0-rc.0 from 2025-01-13, 1.10.0-rc.1 from 2025-03-19 and 1.10.0-rc.3 from 2025-03-31, all release candidates. package.json reads 1.10.0-rc.1, and the last push to the repository was on 2026-10-06.

### What licence is ReNative released under?

ReNative is MIT licensed, with a LICENSE file at the repository root and the MIT declaration in package.json. The project also carries FUNDING.yml and an OpenCollective backers badge, and it lists two core maintainers, Pavel Jacko and Mihai Blaga.

## Sources

- [flexn-io/renative on GitHub](https://github.com/flexn-io/renative)
- [License: MIT](https://github.com/flexn-io/renative/blob/main/LICENSE)
- [Project website](https://renative.org)
- [README](https://github.com/flexn-io/renative/blob/main/README.md)
- [Releases](https://github.com/flexn-io/renative/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flexn-io-renative