Windows 10 support about capacitor HOT 40 CLOSED

Just to add, as Edge adds support for PWAs and allows them to be installed through the Windows App Stores, they'll be able to access devices APIs like web bluetooth automatically as they package the web app up in it's own Windows app shell

from capacitor.

Absolutely, we'd love that

from capacitor.

This does seem to make one thing clear to me though: there's no need for a C# UWP platform. If we do decide to interface with UWP APIs directly, we could do it in JS much like we do the electron plugins. That sound right?

from capacitor.

With PWA going mainstream with Windows 10 Spring Creator Update (March 2018) and Microsoft store along with native API support, I wish UWP implementation is supported.

Here you can find Microsoft's latest announcements over PWAs on Windows 10 and Microsoft store.

from capacitor.

@RichiCoder1 awesome, and this feels like a value prop for Capacitor. We can help you use those APIs without having a bunch of UWP code in your PWA, which feels antithetical to building a web app. Something to think about for sure.

from capacitor.

@RichiCoder1 I agree that for simpler apps and for apps that target just windows UWP may be a better option, UWP with Capacitor is for sure a route worth exploring and one I'd be glad to help with.

from capacitor.

Yep once we get there it’d be “capacitor add windows”

from capacitor.

So the community could provide the Win10 implementation as an alternative to the Electron implementation?

from capacitor.

This is better suited to the community organization, and I have generated a proposal over there to track interest and ideas.

capacitor-community/proposals#26

from capacitor.

Our initial goal was to support Windows through electron

from capacitor.

Will there be a default way to install a external capacitor-windows into a project?

from capacitor.

Nice.

(Imagine reading this a year ago, how crazy this would have sounded)

from capacitor.

Isn't this an argument against UWP implementation? It actually won't be needed as PWA will get the same features and store support as normal UWP apps.

from capacitor.

I'd love to not have to do anything, but wouldn't the PWA still be limited to browser APIs? I think Electron is a better option here

from capacitor.

I would say capabilities increase from PWA to UWP with Webview to Electron.

UWP vs. Electron is probably decided by how good Edge is support by your app or if you need anything Electron can do, that UWP can not.
Anecdotally (startup) performance of UWP/Webview is much better than Electron.

I guess someone will have to find out ;)

(I spend some time with cordova-windows right now, and as I know the code it is actually not very complicated if you only have to support Win10 - so a capacitor-uwp would probably not that hard to build.)

from capacitor.

The advantage of electron is it also supports other OSs (Mac, Linux), even if PWAs can get full UWP features in Windows 10, that's not true for Mac and Linux. So we will still need electron anyway for those (if we plan to support them).

from capacitor.

I understand that Electron is a must to reach Windows, MacOS and Linux. But I wish we support UWP additionally. That way we can build modern apps with Cortana, Timeline integration(though plugin maybe) which can also be installed on PC, Xbox, Windows Mixed Reality, Mobile(not relevant now) etc. I think adding additional UWP support will beneficial for future.

from capacitor.

To me, UWP still has some good arguments over Electron.

Lets sort out some requirements for discussing the reasons behind the preferences for Electron vs. UWP.

Please add to this.

What is the overall goal? Economically reaching different platforms?

Target group

• frontend web developers

Reaching Windows platform

Recency of dependencies, update speed

• Electron continuously lacks a few versions behind the recent desktop Chrome - Electron couples a frontend Chrome with backend node.js via its common V8 version. Upgrading just the frontend Chrome when it arrives is not possible, as the V8 engine version needs to be matched by a corresponding node.js version.

--> go for UWP

Consistency native vs. web-based version on platform for developers

• Edge engine support required for PWAs - Windows & Edge will support natively progressive web apps. With its large desktop market share, it will require software developers to test for the Edge engine.

• When using Electron for Windows apps, the app's behaviour will differ from the platform's default browser. This could confuse users and more likely will confuse developers developing on windows.

--> go for UWP

Ease of development for (frontend) web-developers

• Electron has a different api architecture compared to Cordova even for basic frontend features like the camera. This requires extra & dedicated development effort.

--> go for UWP

Leverage existing ecosystem

• Leverage cordova-windows plugin ecosystem - There are quite a few maintained plugins for cordova-windows.

--> go for UWP

App performance (bundle size, startup time, execution complexity)

• bundle size - Electron increases package file sizes by a number of magnitudes - UWP adds only 2-3mb to create a Store-ready distributable. With Electron and its packed node.js dependencies this size inflates at least tenfold.

• startup time - Electron seems to be slower on startup (has been mentioned above)

--> go for UWP

Reaching macOS platform

• macOS will the same frameworks as iOS - Apple is on the verge of integrating the iOS & macOS application frameworks - to be announced this summer. Within the next 2-3 years there will be only the iOS-championed APIs with macOS APIs mostly being integrated into the iOS APIs.

--> Why invest with Election into a separate architecture for a comparatively low-volume operating system where the unification effort is in the making and soon to be announced.

--> go for iOS-compatible implementation

Reaching linux platform

to be discussed

from capacitor.

Im going to my two cents in here as a past user UWP who switched up to Electron.

Electron continuously lacks a few versions behind the recent desktop Chrome - Electron couples a frontend Chrome with backend node.js via its common V8 version. Upgrading just the frontend Chrome when it arrives is not possible, as the V8 engine version needs to be matched by a corresponding node.js version.

How close are you getting to the bleeding edge that the version Electron uses doesn't support all the features you need? As of this writing, Electron has Chrome V59 (soon 61 with 2.0) and Chrome desktop is V64, what is different about those is not much, and what is can most likely be a poly-fill for now.

When using Electron for Windows apps, the app's behaviour will differ from the platform's default browser. This could confuse users and more likely will confuse developers developing on windows.

Not sure if I understand where you are getting at with this, but plugins that are built for electron should try and make actions "close to native" feeling. Like using https://electronjs.org/docs/api/dialog for opening/saving files.

Electron has a different api architecture compared to Cordova even for basic frontend features like the camera. This requires extra & dedicated development effort.

I believe this can be addressed through capacitor plugins, all current Core Web plugins work with electron out of the box.

Leverage cordova-windows plugin ecosystem - There are quite a few maintained plugins for cordova-windows.

In time we may be able to load these with a compatibility layer of some sort, no promises though.

bundle size - Electron increases package file sizes by a number of magnitudes - UWP adds only 2-3mb to create a Store-ready distributable. With Electron and its packed node.js dependencies this size inflates at least tenfold.

Yep, I agree. Bundles are bigger for electron, but they're getting better, there is also a couple of projects and whispers of being able to use local chrome, you would provide 2 installers, one self contained, the other if you have chrome installed, but agian nothing concrete on this, just some things I've seen around.

macOS will the same frameworks as iOS - Apple is on the verge of integrating the iOS & macOS application frameworks - to be announced this summer. Within the next 2-3 years there will be only the iOS-championed APIs with macOS APIs mostly being integrated into the iOS APIs.

Until this happens you can just target macOS with Electron build tools, after it does capacitor's iOS support should be a great option.

Reaching linux platform

Electron supports linux, even with arm architecture.

from capacitor.

To clarify, a PWA gets UWP APIs only when an PWA is packaged as an appx and installed through the store. Otherwise, it just has access to normal browser APIs. However, in my brief experience, this really is a low friction process to package a PWA (see https://pwabuilder.com) and a lot more pleasant than having to deal with Electron (at least for Windows 10) while getting access to all the UWP APIs. Seems a no brainer to add support for packaging and plugins.

from capacitor.

How does a PWA go about accessing UWP apis on windows? Is there any example of this? Would be curious to see/learn

from capacitor.

@RichiCoder1 out of curiosity what gave you issues with Electron? I use it all the time and haven't had any issues doing anything

from capacitor.

@mlynch See https://twitter.com/AaronGustafson/status/976650841070407681
Basically if it's available to UWP Javascript apps, PWA's can use it. Which means just about everything in UWP. All you have to do is test for 'Windows' in window. There's some color around permissions, but otherwise, it just works. Was talking with the Twitter PWA devs about lighting up Share and UserActivity (aka Windows Timeline) support not too long ago.

Extra docs
https://docs.microsoft.com/en-us/scripting/jswinrt/using-the-windows-runtime-in-javascript

@IT-MikeS Honestly, lots of subtle compatible issues with display (HiDPI specifically, though it's gotten tremendously better), memory weight (except for exceptional apps like VS Code), and package size mostly. It's an experience that just feels rough. If Capacitor can deliver however, and make it so that packaging and plugins work seamlessly? I couldn't then see a reason to use Electron over UWP/PWA unless you really needed some bleeding edge Chrome or Node APIs.

from capacitor.

Okay, so you could use like, the payments API here by accessing window.Windows.ApplicationModel.Payments? https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.payments

from capacitor.

@mlynch Looking over the docs, it looks like the answer is yes. I think about the only things you can't take advantage of it's APIs that have to do with actually activating the App. I could be totally wrong though.

from capacitor.

@RichiCoder1 HiDPI has and continues to get better and better but yes it was a bit off. Memory weight is honestly something I have never had an issue with personally, even in my largest application I've only seen a max of 130 ish MB of memory usage which isn't small but in today's world is not a lot compared to installed memory. I will completely agree with you that packaged sizes of electron apps can be really quite big but they are looking at that from what I hear. One of the biggest reasons I got away from UWP is I found there wasn't anything that UWP offered me that Electron didn't (Haven't revisited for a bit so this may not be the case now) and I got all of the Node API good-ness with cross platform compatibility, one code-base multiple targets.

from capacitor.

@IT-MikeS And to each their own. I think there are absolutely valid reasons to go Electron still, especially if you're building Apps that have more sophisticated interactions with the host system and are targeting multiplatform. But I think that argument erodes when you're talking about simpler apps or PWA-first apps, and you're already using an abstraction like Capacitor's plugins. All the effort then gets shifted to the plugin developers (which is obviously a concern and a factor in all this). But then if you can target the same APIs, why would you then choose Electron over UWP when targeting Windows? Especially if (and this is the big, to be tested if) the latter can provide a better UX to the end user. Hence why I strongly support his issue, especially on top of the great direction Ionic and Capacitor is already going

@mlynch Exactly! It's the biggest thing that's made me excited about PWA support in Windows

from capacitor.

Very interesting discussion. Just add my 2 cents worth, and hope it does not go too off topic.

In my case, I currently have have an Ionic/Cordova UWP version of my app deployed to the Windows store. From what I understand, If I went to Capacitor for this app, I'd lose having this on the store (unless it went our as a PWA)? I'd then have to see what I would lose plugin wise.

In another case, I currently have a Windows C#/.net program, that runs on small rugged pen based tablets, I am considering rewriting using Ionic (so can get cross platform support on iOS/Android tablets as well). However, for the time being, Windows would be the main platform it would run on. This app will need heavy offline/database support with quite a lot of data it would download and store, so I would probably want to use the Native sqlite plugin. The exiting app has integrations with the tablets com port (obviously this would only be for Windows), so I would want to extract this code from the existing app, and wrap in a plugin (just for the Windows version), which I would then use in the rewritten Ionic app. This code is in C#, so, from what I understand, I could not use a Electron plugin for this with the existing C# code, unless this was also rewritten. If I had a UWP, I assume I would be able to reuse this code (once put into a plugin)

Lastly I did try a quick Capacitor / Electron app (using Ionic 3 tabs template), and on the tablet mentioned (pretty low spec), it did seem quite slow to startup. This surprised me. I've not done any Electron apps before, but using apps done in Electron (eg vscode) seem so fast to start, I was surprised at the startup time (eg the time the splash screen was displayed). This was sometime ago, so I would want to retry this (and also with Ionic 4 app inside).

from capacitor.

By default the splash screen stayed up longer than it should have before unless you closed it explicitly, so that could explain it. No other reason it should be slower

from capacitor.

Have you tried UWP PWA?

https://developer.microsoft.com/en-us/windows/pwa

For a basic test, is just a:

1. Create new project
2. Configure some names and icons
3. Insert the PWA url
4. Build

Example: https://bit.ly/divaWindows10

from capacitor.

Edge is transitioning to chromium now, so only edge (heh) electron has over doing UWP PWA will be backend nodejs libraries, but maybe with UWP PWA being based around v8 we'll get some sort of nice API for running backend code? only time will tell.

from capacitor.

However, leaving linux out to dry is not something some people are willing to do, so electron will be needed for a while until there's some sort of native API implementation for linux for PWA's (once PWA's are even supported on linux)

from capacitor.

Nearly a year later... It's a shame this is marked low priority, given how easy it is to package a PWA as a side-loadable .appx, or for the Store, and gain access to the full WinRT APIs, including Storage, persistent Filesystem access with a picker, etc. Electron is all well-and-good, but the package sizes it produces are ridiculous, clunky and resource-intensive for a simple PWA. A highly functional Web App with Filesystem access is as small as 2 MB in UWP, whereas Electron requires > 110 MB for the exact same app.

from capacitor.

Why are all the proposals for Windows 10 being closed? Now with Core OS coming out and insane market share it would be stupidity not to develop for the ecosystem.

from capacitor.

@antonioberetini what is Core OS?

We're certainly paying attention to the interest around Windows support. Not a bug with Capacitor so we close but want to keep the discussion open.

from capacitor.

from capacitor.

We'll keep it on our radar. One thing I wasn't sure about was whether access to the WinRT APIs was going to disappear. Do you know anything about that? Also if you're building a PWA there's no reason you can't target Windows 10 today, but you'd have to be okay with the APIs available to you in the sandbox.

from capacitor.

from capacitor.

If I could, just a reminder this the issue area for Capacitor, and there is a good place for suggestions over in the Capacitor Community Org. here on Github (https://github.com/capacitor-community).

There is even a Windows 10 specific platform suggestion open there, where things like these useful pieces of info will be better kept and viewed (capacitor-community/proposals#26)

from capacitor.

Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Capacitor, please create a new issue and ensure the template is fully filled out.

from capacitor.