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’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.
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!
Regards the In-App Purchases for PWA, I see this in the headline:
how we wrangled Swift to integrate in-app purchases in iOS PWAs
I’m not in a position where I can afford to do any “wrangling” to get basic things like purchases to work. It just works in Capacitor and Cordova. That’s what developers are expecting.
If Meteor want to go PWA instead of Capacitor, that’s fine by me. I just hope it properly supports everything mobile apps need.
The RevenueCat Web SDK uses Stripe, not in-app purchases, so it’s not a substitute.