Does this support social sign-ins?
I don’t see why it wouldn’t. I’m guessing you’d have to use @capacitor/browser or another in-app browser plugin to show the OAuth screens, but that’s probably the same for Cordova right? It’s possible you’d also need to configure deep links for the app to capture OAuth callbacks. Just guessing here; I don’t use social sign-ins in my app, although I do use an in-app browser for other things and I have deep links set up.
Yeah I think there can be an issue where it loads up a clean browser window with no session information, meaning user has to sign into Google/Facebook/etc even if their mobile browser is already signed in. I believe the Meteor-Cordova integration magically handles that, would be great to see that here too if you have plans to make it a Meteor package or merge into Meteor Core.
As far as I’m aware, the only runtime “special sauce” that Meteor adds to the Cordova app is cordova-plugin-meteor-webapp. I intend to replicate all relevant functionality from that plugin, except for the bundled web server (since Capacitor handles that now) and local filesystem access (since it’s no longer trivial given that we’re using Capacitor’s web server, and I think we’re better off leaving that to other plugins). I’ve completed the reimplementation for iOS (pending further testing) and plan to tackle Android soon.
As far as I can tell, cordova-plugin-meteor-webapp doesn’t add any “magic” in terms of sharing session with the system browser, however. I don’t think that’s even possible unless you actually open the system browser, i.e. the OS switches over to Safari or Chrome (or whatever the default browser is) and away from your app. Besides, as far as I know you can’t even open in-app browser windows for the auth in Cordova unless you have one of the plugins; it’s not part of cordova-plugin-meteor-webapp’s API:
declare global {
interface Window {
WebAppLocalServer: {
startupDidComplete(callback?: () => void): void;
checkForUpdates(callback?: () => void): void;
onNewVersionReady(callback: (version: string) => void): void;
switchToPendingVersion(callback?: () => void, errorCallback?: (error: Error) => void): void;
onError(callback: (error: Error) => void): void;
localFileSystemUrl(fileUrl: string): never;
};
}
}
I pushed a bunch of updates to my cordova-plugin-meteor-webapp replacement plugin, capacitor-meteor-webapp.
It’s got Android support now, along with a whole suite of tests for both platforms (and bug fixes to go along with them). I’m feeling a lot more confident in its production-readiness and am going to update my public beta apps (used by a couple hundred folks) to Capacitor very soon.
To be clear: AI agents (Opus 4.6 & Codex 5.3) did all of the coding, though I was heavily involved in the (multiple) planning and review stages. I think the result is better than if I’d done it myself (given that this is out of my wheelhouse as a primarily-web programmer) but I want to be sure to disclose that. I did everything I could to make a robust plugin because the last thing I want is to have thousands of broken app installs on my production app – that would be catastrophic. (Writing that makes me a bit nervous… but that’s why I have a beta version!)
Now to finally integrate RevenueCat! 
Nice stuff!
OMG yes hahaha
How’s the RevenueCat integration going?
Have not gotten to that point yet. Had to prioritize some other things in the backlog. So far so good with Capacitor, though… big public test (probably ~200 people) is coming soon, but internally there have been no issues with the TestFlight version.
Quick update: released a public beta version of my app about ten days ago, powered by Meteor 3.2 (yes I need to update), Capacitor 8, and my capacitor-meteor-webapp plugin, which is now in use by ~100 iOS users. Multiple hot-code pushes since then. Zero issues logged or reported. Feeling good about it. Going to try publishing an Android beta and getting some Android users using it next.
re: RevenueCat @msavin - still haven’t worked on actually integrating the SDK with my codebase, but I got it installed and bundled in the Xcode project. Simple as meteor npm install @revenuecat/purchases-capacitor.
My Meteor-powered Capacitor app (or is it Capacitor-powered Meteor app?) is out of beta on both the Apple App Store and Google Play Store! It will take time for the thousands of users to be updated to the app, but so far there have been zero issues with cross-compatibility. I’m super chuffed with how this all turned out. My @banjerluke/capacitor-meteor-webapp plugin needed no further updates; I’ll probably take off the “WORK IN PROGRESS” scare copy soon.
Oh, and RevenueCat is onboard as well! (In parallel with Iaptic Billing while I complete the transition.)
So everything has been working great… except for one wrinkle that I failed to predict:
Every user found themselves logged out.
Of course, this makes sense. Capacitor and Cordova are using different internal domains, so they have different cookies/localStorage databases. With hindsight, perhaps I could have figured out some way to migrate sessions from Cordova to Capacitor, perhaps by storing the login token in the app “preferences” or somewhere on the filesystem (with an update that I put out well in advance using Cordova) and then fetching that after updating to the new Capacitor-powered app. It’s tricky, though. For some apps, it might not matter, but I have users who have been logged in for years and no longer have access to the email they signed up with, so we had to help them out manually. Plus, some users opened the app where they had no internet connection expecting to be able to use it, but since a background update had moved them over to the new Capacitor app, they found themselves logged out when they opened it up.
Anyway, just wanted to give that heads-up to anyone else considering a Cordova-to-Capacitor migration. FWIW, there have been no other observed or reported issues related to this migration across thousands of app installs and many live Meteor updates as well as several App Store updates.
Congrats. Too bad about the logout wrinkle. Still, quite an achievement if that’s the only significant issue users face (though agreed it’s a big one). Good luck helping them out.
If you have the cycles, consider writing this one up 
It would be so helpful to others modernizing their Cordova apps.
How did you achieve your offline capability in your Capacitor app?
Those unexpected turns with forced logouts etc are part of the learning I guess. Did you migrate them in batches or was this only becoming an issue when you mass migrated them?
Still, congrats on moving them off Cordova and onto Capacitor. What advantages do you users realize on Capacitor or are the only benefits on your end?
Offline capability is through IndexedDB via Dexie and my GroundedCollection wrapper which I posted and wrote about awhile back. (Though I’m in the process of adding @capawesome-team/capacitor-sqlite as a backend for iOS to work around a long-standing WebKit bug with IndexedDB.) No changes from what I was doing in Cordova, which also mirrors what I’m doing in the browser and ToDesktop except I also need a service worker there (powered by Workbox).
Logouts: basically, I released the app to the App Store / Play Store, then as users slowly started to get updated to the latest Capacitor-powered shell they found themselves logged out. So it was a trickle at first, then a river, and now seems to be calming down as most people have been updated at this point. It’s my fault for not properly testing the production deployment using TestFlight. (I did plenty of testing, but on a different TestFlight-only bundle ID, which made me complacent.)
Benefits to users are mostly that I can more easily maintain and improve the software in the future due to more access to modern plugins and build tooling. But I also think that startup times have improved, though I didn’t do any benchmarking.
Pretty sure I’ve written everything someone (or their AI agent) would need to get up and running in the README/documentation for the plugin I made, which includes a sample build script as well. Happy to answer questions if anyone finds gaps in that documentation while attempting their own migration. I suspect some aspects of it may change with upcoming Meteor versions in the not-too-distant future. Also, caveat that I’m using meteor-vite for builds; I suspect an Rspack-powered app would work even smoother but I’m not sure as I can’t use Rspack and have Svelte hot-reload.
@banjerluke Thank you very much for your effort! 
I have just successfully migrated from Cordova to Capacitor - things work much-much better - finally I can work on the Safari browser extension (with Cordova it was very messy). I did not release yet, but given the most job is done in Xcode now, I hope it will work. Did not try the Android yet though, we’ll see. Looking forward for native Capacitor support in Meteor. 
Honestly, after Cordova, no needing to regenerate the Xcode project is such a relief…
Perfect timing to say that Meteor CapacitorJS integration in the core is already implemented and functional.
We will start a period of iterations until we can have the Meteor release queue free to actually have CapcitorJS published as a beta, but in the meantime anybody interested can get closer to the Meteor development lifecycle and provide feedback about it.
@nachocodoner Hey, that’s fantastic news! I was just going to update my plugin with some dev-tooling improvements I’ve done locally (to make HCP work with my meteor-vite dev server, big quality-of-life improvement) but now I will also compare against the PR. Happy to see you were able to build off of my capacitor-meteor-webapp plugin, which for the record is now serving thousands of my users across iOS and Android with no observed or reported issues over several App Store updates and dozens of HCPs.