-
Notifications
You must be signed in to change notification settings - Fork 964
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows 10 support #92
Comments
Our initial goal was to support Windows through electron |
Will there be a default way to install a external |
Yep once we get there it’d be “capacitor add windows” |
So the community could provide the Win10 implementation as an alternative to the Electron implementation? |
Absolutely, we'd love that |
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 |
Nice. (Imagine reading this a year ago, how crazy this would have sounded) |
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. |
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. |
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 |
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. I guess someone will have to find out ;) (I spend some time with |
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). |
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. |
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
Reaching Windows platformRecency of dependencies, update speed
--> go for UWP Consistency native vs. web-based version on platform for developers
--> go for UWP Ease of development for (frontend) web-developers
--> go for UWP Leverage existing ecosystem
--> go for UWP App performance (bundle size, startup time, execution complexity)
--> go for UWP Reaching macOS platform
--> 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 platformto be discussed |
Im going to my two cents in here as a past user UWP who switched up to Electron.
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.
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.
I believe this can be addressed through capacitor plugins, all current Core Web plugins work with electron out of the box.
In time we may be able to load these with a compatibility layer of some sort, no promises though.
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.
Until this happens you can just target macOS with Electron build tools, after it does capacitor's iOS support should be a great option.
Electron supports linux, even with arm architecture. |
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. |
How does a PWA go about accessing UWP apis on windows? Is there any example of this? Would be curious to see/learn |
@RichiCoder1 out of curiosity what gave you issues with Electron? I use it all the time and haven't had any issues doing anything |
@mlynch See https://twitter.com/AaronGustafson/status/976650841070407681 Extra docs @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. |
Okay, so you could use like, the payments API here by accessing |
@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. |
@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. |
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? |
@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 |
@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. |
@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. |
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). |
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 |
Have you tried UWP PWA? https://developer.microsoft.com/en-us/windows/pwa For a basic test, is just a:
Example: https://bit.ly/divaWindows10 |
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. |
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) |
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. |
This is better suited to the community organization, and I have generated a proposal over there to track interest and ideas. |
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. |
@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. |
Well this area is meant for plug-in ideas not bug reporting.
CoreOS is the base od the new windows versions built around unified core thats shared across all debice types with adjustable user facing shell/Interface. The first consumer product with this version of the os is the new Windows 10X which is scheduled to launch this summer.
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Max Lynch <notifications@github.com>
Sent: Monday, February 22, 2021 11:03:46 PM
To: ionic-team/capacitor <capacitor@noreply.github.com>
Cc: Tony Beretini <tony@get-local.app>; Mention <mention@noreply.github.com>
Subject: Re: [ionic-team/capacitor] Windows 10 support (#92)
@antonioberetini<https://github.com/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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#92 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APUUMIA56NW2YFL7URRN3ZLTAMZLFANCNFSM4ENO722Q>.
|
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. |
I would suggest reading through this repo: https://github.com/microsoft/ProjectReunion
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Max Lynch <notifications@github.com>
Sent: Monday, February 22, 2021 11:13:46 PM
To: ionic-team/capacitor <capacitor@noreply.github.com>
Cc: Tony Beretini <tony@get-local.app>; Mention <mention@noreply.github.com>
Subject: Re: [ionic-team/capacitor] Windows 10 support (#92)
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#92 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APUUMIHEII2TJJVCUZ43E4DTAM2QVANCNFSM4ENO722Q>.
|
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) |
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. |
Is there any future plans to support windows 10? There are now almost 1 billion windows 10 devices out there and more being added all the time.
The text was updated successfully, but these errors were encountered: