GeezerVison is showing github.com — Support for desktop OSs (OSX, Windows, Linux) · Issue #27 · NativeScript/NativeScript
Support for desktop OSs (OSX, Windows, Linux) #27DescriptionThis would be a killer feature. If you even made a layer for NW.js, that would be awesome.
Please vote for this issue in our ideas portal.
Please don't write a comment saying +1. Instead vote for it in the ideas portal or by hitting the quick reply buttons just below this post.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Reacted by troorl, Gregor B. Rosenauer, Nikolay Artamonov, Pavan Podila, Leopold Luley, Curciel, hujinq, Xy Ma, Habib Kazemi, alex-erygin and 271 more Reacted by dennisbrandenberger, Prasanth Venugopal, inssitu, geminiyellow, Mehmet Yildiz, Richard King, David Grieshammer, Dheepak Krishnamurthy, Sajjad Servatjoo, Whit Huntley and 13 more Reacted by Paulo Coutinho, Brian Webb, Kjetil Geirbo, inssitu, Yeikel Santana, Mehmet Yildiz, Richard King, David Grieshammer, Annika, Dheepak Krishnamurthy and 25 more Reacted by víctor Activitykasajian commented on Apr 6, 2015 Sibling10 commented on Apr 24, 2015 +1 - Core dev team might want to take a look at the latest version of WinJS library for ideas. RangerMauve commented on 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 commented on Sep 13, 2015 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 Foscarini, Cristián Pérez, Lesego Mabe and 4 more mrjjwright commented on 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 commented on 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 commented on 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 commented on Oct 30, 2015 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 buu700 commented on 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. Reacted by Paul, Arianit and Martin Braun Reacted by Caesar Schinas anton-staroverov commented on May 7, 2016 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 zakdances commented on 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 commented on Sep 28, 2016 Reacted by Jan Böhler and icode 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 andy-tai-leeco commented on 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 commented on Dec 19, 2016 Are there any plans to support desktop OS in the near future? Maybe macOS? Reacted by Sage Arbor, Mo, Todd Gao, Tarun Elankath, Brian Webb, icode, yellow, Lukas Bombach, tfpdeveloper, Cryptochats and 6 more DrSensor commented on Jan 24, 2020 Reacted by Pavitra Golchha andreasbhansen commented on Mar 10, 2020
is the only way NativeScript can win the popularity contest '__')
Import to remember that search trends ≠ actual industry adoption. Nevertheless, desktop support would be great! Reacted by shreyasm-dev and Arianit redradist commented on 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 commented on Feb 5, 2021 buu700 commented on 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. Reacted by Jamie Birch, ૮༼⚆︿⚆༽つ and Luke Hardiman NathanaelA commented on Mar 4, 2021 buu700 commented on 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. Reacted by Nathanael Anderson, ૮༼⚆︿⚆༽つ and Lukas Hahn suchorski commented on Jun 14, 2021 Reacted by ૮༼⚆︿⚆༽つ, Dušan Gvozdenović, Lukas Hahn and Daniel Herr TheJaredWilcurt commented on 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 commented on 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 commented on 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. Reacted by Philippe Coval and ChrisChou listepo commented on Sep 25, 2025 triniwiz commented on Jun 26, 2026 listepo commented on Jun 28, 2026
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|