Bedankt Koen, good to hear it works. How much work was it to switch from the Meteor-Electron package to this one?
I’ve noticed that Electron is still at version 26, whereas it currently is at version 33 already. How much is this package maintained to stay up-to-date with the rapid new versions that Electron is issuing the last years?
We did not migrate from Meteor-Electron, we used meteor-desktop before: GitHub - wojtkowiak/meteor-desktop: Build a Meteor's desktop client with hot code push.
Electron releases a new version for every Chrome version, so that’s every 8 weeks. 26->33 is 7 x 8 = 56 weeks behind, that’s a single year.
We use a forked version of the package, where we update Electron whenever we want, and we tend not to run into any issues, so it should be fine 
Sorry Koen, that’s the package that I meant, my bad.
Ok, that puts things into perspective.
So you fork it each time a new version of the capacitor-community/electron package comes out and then update it to the latest ElectronJS version with any problems so far?
One more question, do you use any Capacitor specific code? I guess not.
The changes between versions aren’t big, so we just pull in any new versions from the main repo. Also I believe we’ve pushed updates back.
It’s possible to write plugins for Capacitor/Electron, which we do use. I’d just give it a try, we’re doing quite some advanced stuff and haven’t run into any walls yet.
This caught my eye. Had been immersed in the design pattern change away from just client and server to include agents … but as 10 DLC starts to heavily limit SMS / MMS even for P2P uses of A2P, I just want to throw away the entire text messaging convention and do push notifications to a mobile application to achieve the only important thing to us from SMS; which is legacy-style immediacy. Non-savvy types not having to go check your email for a notification for example, in the outdated technical demographic.
It seems you are saying it is not that hard to even bypass separately dealing with Electron and Cordova but to instead implement Capacitor which would then build both mobile and desktop native applications.
Do we have a guess what percentage of Meteor implementors have mobile application deployments? Desktop? Web only? Curious if maybe I pushed this all to the back of my mind because of how much I hated past eras of approach. If it is simpler now and seamlessly compatible with Meteor … I would spike that out right away.
And does anyone use no third-parties for push notifications?
There is no need to deal with Cordova or Capacitor for push notifications. A simple PWA can handle push notifications.
What an awesome link-drop. Thanks so much for the newsflash/update @rjdavid.
PWA sounds of Occam’s razor in my case, on problem framing.
I could hug you for the burst of fresh sanity.
Seems PWA is an area that went a bit dormant?
As mentioned by:
To RTFM here, is there a best source of truth on PWA implementation today, for our v3 life?
Will get up to speed on the Vue side for client changes especially, outside the server portion.
There’s no official word yet from Meteor about moving away from Cordova, but it’s worth staying tuned to their roadmap. Capacitor does offer some great features, though, if you’re thinking about switching!
Really looking forward to moving from Cordova to Capacitor for my app. I would love to switch my in-app billing solution to RevenueCat but couldn’t get the Cordova plugin working. Also excited about the possibility of faster startup times – can’t find the source for why I think this, but I feel like I ran across someone saying their cold-boot times went down after switching.
I have a PWA all set up, but it’s not a replacement for being in the app stores (especially for non-tech-savvy users which are my primary customer). Currently using ToDesktop for an Electron app (so easy) but having Capacitor handle Electron building would be cool too.
Glad to know that Capacitor is on the roadmap and will get some attention from the team after some higher priorities are taken care of.
Our PWAs are available to download in App Store, Play Store and Microsoft Store.
Oh, awesome! Probably not a fit for me because of some custom native Cordova/Capacitor plugins I rely on (mostly to get around Safari/WKWebView limitations/bugs with Web Audio), plus I don’t think this solution would integrate with the “hot code updating” that Meteor does… but for an app that doesn’t need native functionality or that wants to use app store updates as an update channel, this looks great.
It does as what is installed is the PWA. It behaves as how your mobile web app behaves in the OS browser
PWA uses the OS browser without any of the limitations of webviews
In summary, whatever is your mobile webapp, that is the same experience your users will get if they installed your PWA through the app stores. One consistent code-base across all devices
I was going to ask how an app-bundled PWA would store updated code (like the Cordova implementation does) but then I realized the answer is obvious – it would do it just like a PWA does: with a service worker! Nice. 
Apple’s implementation of the Web Audio API is broken at the OS level (unless they fixed it recently). 
So my app doesn’t work well in Safari or an app-bundled WKWebView (which is the same browser engine as Safari). But I’m in a niche situation.
Unfortunately, yes. Browser OS bugs, parity between browser capabilities to native functionalities, and performance are limiting factors of PWA. That’s where Capacitor comes in. (I don’t hope of coming back to Cordova since we dropped it in favor of PWA).
There is hope that Chrome/Google is pushing for that functional parity for Android. Hope in ios seems to rely on how far EU (and the US?) can force Apple. Performance seems like a limitation on the language/engine level (although even Capacitor has that limitation).
I haven’t heard anything official from Meteor about switching from Cordova to Capacitor yet, but with the trend, it could happen eventually. Keep an eye on the roadmap for updates!
It’s official as it’s listed in Candidate items
One limitation - I think - for PWA apps is that they don’t have access to Apple & Google’s store purchases infrastructure.
Mine is a consumer app and I think I would be at a big disadvantage if I couldn’t use app store-managed subscriptions.
And since you are using RevenueCat
) this gregorian year: