You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This'd be pretty cool. And with windows 10 Chakra integration that'd be not too hard, I'd imagine. Maybe it'd also be a step for integrating with windows phone, too.
Reacted by Yeikel Santana, icode and Alexander Mills
Reacted by Karol Mierzejewski, Brian Webb, Rafael Belvederese, Richard King, Whit Huntley, Tobias Kern, Lucia Scarlet, Nick, Cristián Pérez, Lesego Mabe and 4 more
Can somebody talk about the feasibility of doing this. It looks pretty doable based on the iOS runtime as there is a pretty clean layer for calling Objc-C.
Yes it is doable and relatively easy (in a matter of week) a POC app can be created that can show a running MacOS app written in {N} and accessing the native desktop APIs. The real effort will after that when the abstraction layer that will allow you to reuse the UI declarations between mobile and desktop should be written.
I wonder if some of you is interested in doing this POC or dealing with the abstraction layer? It is really not a top priority for the moment and I don't see it becoming a priority in the next 6 months for the core team.
Reacted by Karol Mierzejewski, Brian Webb, Rafael Belvederese, Ivan Kara, Tobias Kern, Lucia Scarlet, 0x1A4, Cristián Pérez, shreyasm-dev, Caesar Schinas and 1 more
If desktop support is a lower priority than mobile, maybe it could be implemented on top of Qt?
Since they've already done the work of wrapping up a JS runtime and cross-platform UI abstraction together, it seems like NativeScript could hypothetically just map its own UI markup's primitives to the equivalent QML code.
Reacted by Karol Mierzejewski, Brian Webb, Rafael Belvederese, Dmitry Demin, Ivan Kara, Tobias Kern, Lucia Scarlet, Javier Alfonso, 0x1A4, Cristián Pérez and 4 more
I don't think QT is needed. Ubuntu already supports QML natively for it's UI markup. And also JavaScript and Swift for it's controller logic.
So only Swift (plus some QML) is necessary to support iOS, OSX, and Ubuntu. But, as mentioned above, the hard part is the API differences.
HOWEVER, with interoperability being an official goal of Swift 3.0, the syntactic differences between Apple APIs (Foundation, AppKit, UIKit, etc) might be lessened. Which should make the {N} abstraction layer easier to create for all 3 platforms.
So perhaps Swift 3.0 is a good runtime target for this goal (even if it temporarily excludes Windows).
Reacted by codec-abc, Brian Webb, Rafael Belvederese, Dmitry Demin, Ivan Kara, Tobias Kern, Javier Alfonso, Cristián Pérez, shreyasm-dev, Caesar Schinas and 1 more
This feature right now is not no optional ... it is almost required to be competitive with other implementations like Flutter, Blazor Mobile Bindings (allow not only use platform API but also use hybrid approach and mix code) and so on
I brought up a similar idea in an earlier comment on this issue five years ago, but would it make sense for NativeScript to target Flutter rather than each platform directly (or as a third "platform" in addition to Android and iOS)? Since Flutter supports desktop platforms, and version 2 released today now has production-quality support for the web, this would kill four birds with one stone.
Alternatively, what about just adding web support and putting a pin in native desktop support? While not ideal, Electron is basically fine on desktop, and being able to target every platform with one code base would be a huge improvement from the current situation where we need to maintain different templates for web and native.
Makes sense! The blog post said production-quality, but upon testing the flutterfolio.com demo, while it looked great at first glance (and is certainly impressive regardless), it spiked my CPU to 50+% just by being open in the foreground and had enough subtle issues that I wouldn't consider using it production in its current form.
And awesome, glad to hear that! I'll go ahead and follow the RFC issue to keep up with the progress.
Reacted by Nathanael Anderson, ૮༼⚆︿⚆༽つ and Lukas Hahn
I would love to see this happening and I think it should head in the direction of UWP on Windows and Mac Catalyst on macOS. The former will be the most work, the latter should be possible easily.
Until this is done, we really have to leverage PWA or things like Electron. True native is different.
Activity
kasajian commentedon Apr 6, 2015
How do I up-vote this?
Sibling10 commentedon Apr 24, 2015
+1 - Core dev team might want to take a look at the latest version of WinJS library for ideas.
RangerMauve commentedon May 21, 2015
This'd be pretty cool. And with windows 10 Chakra integration that'd be not too hard, I'd imagine. Maybe it'd also be a step for integrating with windows phone, too.
joao-parana commentedon Sep 13, 2015
+1
mrjjwright commentedon Oct 23, 2015
Can somebody talk about the feasibility of doing this. It looks pretty doable based on the iOS runtime as there is a pretty clean layer for calling Objc-C.
valentinstoychev commentedon Oct 26, 2015
Yes it is doable and relatively easy (in a matter of week) a POC app can be created that can show a running MacOS app written in {N} and accessing the native desktop APIs. The real effort will after that when the abstraction layer that will allow you to reuse the UI declarations between mobile and desktop should be written.
I wonder if some of you is interested in doing this POC or dealing with the abstraction layer? It is really not a top priority for the moment and I don't see it becoming a priority in the next 6 months for the core team.
alexrainman commentedon Oct 26, 2015
I wish you keep mobile separated from desktop development. Please, keep the core lite. This can be somekind of optional plugin, dont you think?
listepo commentedon Oct 30, 2015
+1
buu700 commentedon May 5, 2016
If desktop support is a lower priority than mobile, maybe it could be implemented on top of Qt?
Since they've already done the work of wrapping up a JS runtime and cross-platform UI abstraction together, it seems like NativeScript could hypothetically just map its own UI markup's primitives to the equivalent QML code.
anton-staroverov commentedon May 7, 2016
+1
zakdances commentedon Jul 27, 2016
I don't think QT is needed. Ubuntu already supports QML natively for it's UI markup. And also JavaScript and Swift for it's controller logic.
So only Swift (plus some QML) is necessary to support iOS, OSX, and Ubuntu. But, as mentioned above, the hard part is the API differences.
HOWEVER, with interoperability being an official goal of Swift 3.0, the syntactic differences between Apple APIs (Foundation, AppKit, UIKit, etc) might be lessened. Which should make the {N} abstraction layer easier to create for all 3 platforms.
So perhaps Swift 3.0 is a good runtime target for this goal (even if it temporarily excludes Windows).
icode commentedon Sep 28, 2016
+1
andy-tai-leeco commentedon Oct 19, 2016
no Swift. Why adding a dependency on a language not absolutely needed for the desktop, in the sense of Java being needed for Android.
hypery2k commentedon Dec 19, 2016
Are there any plans to support desktop OS in the near future? Maybe macOS?
23 remaining items
DrSensor commentedon Jan 24, 2020
I think this project worth to look at.
https://github.com/tauri-apps/tauri
andreasbhansen commentedon Mar 10, 2020
Import to remember that search trends ≠ actual industry adoption. Nevertheless, desktop support would be great!
redradist commentedon Feb 5, 2021
This feature right now is not no optional ... it is almost required to be competitive with other implementations like Flutter, Blazor Mobile Bindings (allow not only use platform API but also use hybrid approach and mix code) and so on
NathanaelA commentedon Feb 5, 2021
buu700 commentedon Mar 3, 2021
I brought up a similar idea in an earlier comment on this issue five years ago, but would it make sense for NativeScript to target Flutter rather than each platform directly (or as a third "platform" in addition to Android and iOS)? Since Flutter supports desktop platforms, and version 2 released today now has production-quality support for the web, this would kill four birds with one stone.
Alternatively, what about just adding web support and putting a pin in native desktop support? While not ideal, Electron is basically fine on desktop, and being able to target every platform with one code base would be a huge improvement from the current situation where we need to maintain different templates for web and native.
NathanaelA commentedon Mar 4, 2021
buu700 commentedon Mar 4, 2021
Makes sense! The blog post said production-quality, but upon testing the flutterfolio.com demo, while it looked great at first glance (and is certainly impressive regardless), it spiked my CPU to 50+% just by being open in the foreground and had enough subtle issues that I wouldn't consider using it production in its current form.
And awesome, glad to hear that! I'll go ahead and follow the RFC issue to keep up with the progress.
suchorski commentedon Jun 14, 2021
+1
TheJaredWilcurt commentedon Jun 19, 2021
Could I get some help adding NativeScript-vue into this Desktop + Web boilerplate? It's set to build for both:
There are branches for Vue 2 and Vue 3.
rzr commentedon Jan 27, 2022
I have interest for GNU/Linux support
May top post be edited since URL is gone:
Relate-to: NativeScript/rfcs#11
martin-braun commentedon Jun 23, 2022
I would love to see this happening and I think it should head in the direction of UWP on Windows and Mac Catalyst on macOS. The former will be the most work, the latter should be possible easily.
Until this is done, we really have to leverage PWA or things like Electron. True native is different.
listepo commentedon Sep 25, 2025
Hi @triniwiz any news?
triniwiz commentedon Jun 26, 2026
@listepo I got something working
you can try this sample app https://github.com/triniwiz/nativescript-windows-pokedex
listepo commentedon Jun 28, 2026
@triniwiz thanks, so nice