Hi,
I saw today that RevenueCat’s Cordova plugin is marked as deprecated. RevenueCat is a very popular subscription and analytics tool. It seems they are advising people to switch to Capacitor.
Does Meteor have any plans to do the same? I see some mention of it at Roadmap | Docs
Thanks,
G
Capacitor is definitely on the roadmap, alongside other priorities. We need to give more attention to one of the key tools that defines Meteor: the ability to deploy web apps across multiple platforms. Currently, Cordova handles this, and while it’s still enough for many projects, it becomes limiting over time, similar to the limitations we faced with older Node versions in Meteor 2. Unlocking Capacitor will keep us modern and enable the creation of more powerful hybrid apps. When it comes to maintenance and modern plugins, Capacitor is the tool.
Adding Capacitor would be a great step forward for Meteor and we are definitely willing to work on it as part of future work. Our current focus is on Meteor 3 performance, Change Streams, and TypeScript, check out this post. Adopting a modern bundler might come after that. Ideally, Capacitor would be adopted around the same time or soon after.
In the meantime, at least maintenance updates will be perserved on the plugin you mention, RevenueCat/cordova-plugin-purchases. Although it appears the plugin sets a deadline for users on August 31st, 2026 due to Google´s deprecation on billing client.
Are we talking here about mobile only or also Desktop apps?
Because we have @meteor-community/meteor-desktop package that could need some love too 
If Capacitor will replace Cordova as a core integration, then it makes sense to make the Electron support through Capacitor.
We are already using this in production, it works perfectly fine:
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.
) this gregorian year: