Open-source project
nativescript-vue/nativescript-vue avatar
nativescript-vue/nativescript-vue

NativeScript-Vue 3: A Vue 3 Renderer for Truly Native Mobile Apps

Native mobile applications using Vue and NativeScript.

6,466 stars267 forksTypeScriptMIT

At a glance

What is it?
NativeScript-Vue 3 renders Vue 3 components to native iOS and Android views instead of a WebView, and the v3.1.2 release on 2026-09-15 shows the project is still moving. Here is how the renderer works, how to start a project, and where it stops being the right choice.
Who is it for?
Adopt NativeScript-Vue 3 if you already know Vue 3 and need native views on iOS and Android without a WebView, and you accept that the toolchain is the NativeScript CLI plus webpack, not Vite. Do not adopt it if you want a browser-based renderer or a Vite-first workflow, since the README only documents ns create and ns run.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 2 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What NativeScript-Vue 3 Is For

NativeScript-Vue 3 is a Vue 3 renderer for NativeScript. The package description in package.json says exactly that: "Vue 3 renderer for NativeScript." It is not a framework that wraps a WebView, and it is not a Vue plugin you drop into an existing web app. It takes Vue 3 components and turns them into native iOS and Android views through NativeScript's runtime.

The audience is narrow and specific. You need to know Vue 3 already, or be willing to learn it, because the component model, reactivity system and plugin system are Vue's. You also need to accept NativeScript's build chain, which is the ns CLI. The README's Quick Start offers two entry points: a StackBlitz template for people who want to see the thing run before installing anything, and a local setup for real work.

What it solves is the gap between "I write Vue" and "I need a native app." The README notes that this version brings "improved reactivity, a modern plugin system, and better TypeScript support," which is a fair summary of the v3 work. If your team already has Vue 3 code and skills, the renderer lets you reuse the mental model rather than switch to a different component syntax.

How the Renderer Turns Vue Components into Native Views

The package.json dependencies tell you most of the architecture. nativescript-vue depends on @vue/compiler-sfc, @vue/runtime-core and @vue/shared, plus set-value and vue-loader. The runtime-core dependency is the giveaway: NativeScript-Vue implements Vue 3's custom renderer interface, so the same reactivity and component lifecycle that drive the DOM renderer drive native view creation instead.

vue-loader is in the dependency list because single-file components still need to be compiled. The renderer consumes the compiled component and maps its render output to NativeScript views. @vue/compiler-sfc handles the .vue file parsing. set-value is a small utility, and its presence suggests nested property assignment during view setup, though the README does not document that path.

The peer dependencies set the hard boundaries. @nativescript/core must be >=8.9.0, and @vue/devtools is declared as a peer at ^8.0.0. The devtools peer is optional in practice: the README says it is not pulled in because it depends on Electron, and you install it yourself with npm i -D @vue/devtools@^8. The engines field requires Node >=20, which is a real constraint if you are on an older LTS line.

TypeScript support is a first-class concern in v3. The README states that types for every core element, $navigateTo, $showModal "and friends" ship with the package. Third-party libraries such as Pinia or vue-i18n augment the vue module, and code often imports from vue. The templates map vue to nativescript-vue in tsconfig.json so both resolve.

Installing NativeScript-Vue and Running a First App

The README gives a local setup path using the NativeScript CLI. The first command scaffolds a project from the blank template, and the second runs it on a device or simulator. Note the @latest tag on the template, which is how the README writes it.

bash
ns create myAwesomeApp --template @nativescript-vue/template-blank@latest

cd myAwesomeApp
ns run ios|android

After ns create finishes, you have a project directory with App_Resources, nativescript.config.ts and a src folder, matching the layout visible in the demo/ directory of the repository. The ns run command builds and deploys; the README writes the platform as ios|android, meaning you pick one.

If you would rather not install anything yet, the README points at a StackBlitz template under packages/stackblitz-template with a Home.vue entry file. That is the fastest way to see the component model before committing to a local toolchain.

For an existing project, the README gives a tsconfig.json addition so that imports from vue resolve to nativescript-vue. This matters when a library augments the vue module and your own code imports from vue at the same time.

json
{
  "compilerOptions": {
    "paths": {
      "vue": ["./node_modules/nativescript-vue"]
    }
  },
  "vueCompilerOptions": {
    "lib": "nativescript-vue"
  }
}

The vueCompilerOptions.lib key is what tells the Vue language tooling to treat nativescript-vue as the renderer library. Without it, editor support for native-only elements can be wrong.

Debugging with Vue Devtools and the Android Cleartext Trap

Devtools are not bundled. The README is explicit: install the standalone devtools in your app because the dependency on Electron keeps it out of the package.

bash
npm i -D @vue/devtools@^8
ns run ios|android --env.vueDevtools

The devtools window opens on the host machine and the app connects to it. A free port from 8098 up is picked automatically. You can pin a port with --env.vueDevtoolsPort=9000, point at a host with --env.vueDevtoolsHost=http://192.168.1.10 when testing on a physical device, skip launching the devtools app with --env.vueDevtoolsSpawn=false when one is already running, and log socket traffic with --env.vueDevtoolsDebug.

The Android part is where people get stuck. The README instructs you to enable cleartext HTTP traffic in AndroidManifest.xml by adding android:usesCleartextTraffic="true" to the application element. That is a security-relevant change, and the README presents it as a requirement for the devtools connection rather than a production setting. Treat it as a development-time flag and check what your release manifest contains.

The flag surface here is unusually well documented for a devtools integration. The port range, the host override and the spawn toggle each solve a distinct problem: port collisions, physical devices on a LAN, and a devtools instance you already have open.

Where NativeScript-Vue 3 Is the Wrong Tool

The clearest limitation is the build tooling. The repository contains nativescript.webpack.js at the top level and @nativescript/webpack in devDependencies. The README's setup path is ns create plus ns run, both of which go through the NativeScript CLI. There is a demo-vite/ directory in the repository, so Vite is being explored, but the README does not document a Vite workflow, and "nativescript vue vite" is a search phrase people use precisely because the answer is not in the quick start. If your team has standardized on Vite, you are reading the source, not the docs.

The second limitation is the peer dependency floor. @nativescript/core must be >=8.9.0, and the devDependencies pin ~9.1.1. If your project is on an older NativeScript core, upgrading the renderer means upgrading the runtime, which is a larger change than a package bump.

The third is the devtools story. Because @vue/devtools depends on Electron, it is a peer you install manually and run as a separate desktop application. That is a heavier debugging loop than a browser extension, and on Android it forces the cleartext manifest change. If your threat model forbids cleartext traffic even in debug builds, this integration is not for you.

Finally, this is a renderer, not a UI kit. The README does not describe a component library. You get Vue 3 semantics mapped to NativeScript views, and everything above that, including navigation patterns beyond $navigateTo and $showModal, is on you.

NativeScript-Vue 3 Against React Native and Capacitor

The comparison people search for is NativeScript-Vue versus React Native, and the difference is the rendering target plus the language. React Native renders to native views through its own bridge and component set, and its ecosystem assumes React. NativeScript-Vue renders to native views through NativeScript's runtime and assumes Vue 3. Both avoid a WebView; the choice is mostly which component model your team already writes.

Against Capacitor the difference is starker. Capacitor runs a web app inside a WebView and exposes native capabilities through plugins. NativeScript-Vue does not have a WebView layer in the path described by the README: the Vue component tree is compiled and mapped to native views. That changes both the performance profile and the debugging model. A WebView app can be inspected with browser tooling; NativeScript-Vue needs the standalone devtools described above.

Against plain NativeScript the difference is the component model. NativeScript gives you native views and JavaScript or TypeScript; NativeScript-Vue gives you the same views with Vue 3's reactivity, single-file components and plugin system. The README's mention of Pinia and vue-i18n augmenting the vue module is the practical payoff: Vue ecosystem libraries that only need the vue module can work inside the renderer.

The honest framing is that this is not a better-or-worse question. It is a question of whether your team writes Vue and wants native views, in which case the renderer is the shortest path, or whether you want a browser runtime and web tooling, in which case Capacitor is the closer fit.

Maintenance, Licensing and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-15, with v3.1.2 released the same day. The three most recent releases, v3.1.0, v3.1.1 and v3.1.2, all landed on 2026-09-14 and 2026-09-15, so this is a project with current activity rather than a dormant one. That is a statement about dates, not a promise about the future.

The licence is MIT, declared in package.json and present as a LICENSE file at the repository root. MIT is permissive: it allows commercial use, modification and redistribution with the licence and copyright notice retained. That is the general shape of the licence, not legal advice, and if your organisation has specific obligations around attribution or patent terms you should read the LICENSE file itself.

Upgrade cost has two components. The first is the Vue 3 baseline: the package depends on @vue/compiler-sfc, @vue/runtime-core and @vue/shared at ^3.5.42, so the renderer tracks Vue 3.5.x. The second is the NativeScript core floor of >=8.9.0. Moving from v2 to v3 is not a package bump; the README points to a dedicated Upgrade Guide at nativescript-vue.org/docs/essentials/upgrade-guide, and the v2 code now lives on the v2 branch. If you are still on v2, the upgrade is a migration with its own document, not a changelog read.

The Node engine requirement of >=20 is worth checking before you start, because it rules out older build images.

Editorial conclusion

Adopt NativeScript-Vue 3 if you already know Vue 3 and need native views on iOS and Android without a WebView, and you accept that the toolchain is the NativeScript CLI plus webpack, not Vite. Do not adopt it if you want a browser-based renderer or a Vite-first workflow, since the README only documents ns create and ns run. Before committing, verify that your target devices satisfy the @nativescript/core >=8.9.0 peer dependency, that your Node version meets the >=20 engine requirement, and that the Android cleartext flag is acceptable in your manifest, because the devtools connection needs it.

Frequently asked questions

What is NativeScript used for?

NativeScript-Vue is a Vue 3 renderer for NativeScript, used to build native iOS and Android applications from Vue 3 components. The package description in package.json states it plainly, and the README describes it as supporting Vue 3 with improved reactivity, a modern plugin system and better TypeScript support.

Is NativeScript better than React Native?

The README does not make a quality claim either way. The concrete difference it supports is the rendering target and language: NativeScript-Vue maps Vue 3 components to native views through NativeScript's runtime, while React Native renders native views through its own bridge and assumes React.

Is Vue really better than React?

This is not something the NativeScript-Vue material answers. What it does show is that the renderer assumes Vue 3: it depends on @vue/compiler-sfc, @vue/runtime-core and @vue/shared, and its templates map the vue module to nativescript-vue in tsconfig.json.

nativescript vue vs flutter

The README and repository files do not mention Flutter, so no comparison can be made from this material. What is documented is that NativeScript-Vue 3 is a Vue 3 renderer for NativeScript, with a peer dependency on @nativescript/core >=8.9.0 and a Node engine requirement of >=20.

Official sources

  1. License: MIT
  2. nativescript-vue/nativescript-vue on GitHub
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/nativescript-vue-nativescript-vue.svg)](https://hysenlabs.com/projects/nativescript-vue-nativescript-vue)