Meteor Cordova Integration: next steps

Hi guys, I just want to be sure everybody is aware of our plans for the future of Meteor and Cordova.

Long story short: :exclamation::exclamation::exclamation:We (Meteor Software Ltd., the new company behind Meteor, a Tiny company) want to keep Meteor working very well and up-to-date with Cordova :exclamation::exclamation::exclamation:

I’m posting this here because of this issue

Let’s discuss the next steps here.


As mentioned in the issue on GitHub I think Meteor should provide a reference implementation for Cordova, just like it does for React, Vue and Angular.

In a world where React Native, Flutter, Ionic, Electron and maybe even most interestingly Capacitor are taking care of providing any (Web) App with a (cross-platform) native layer Meteor should in my opinion not invest heavily in supporting a single platform.

The Cordova integration currently boils down to:

  • some CLI commands which map to Cordova commands;
  • a build step which copies the Meteor app into the Cordova project;
  • a plugin which both serves the Meteor app files to the Cordova WebView and enables Hot Code Push.

All of these things could easily be abstracted away from a specific integration between Meteor and Cordova (take the meteor-desktop (Electron) project for example) and allow for a more generalized integration.

For us it doesn’t matter really, we are slowly migrating away from Cordova either way (currently our best bet is on Capacitor), but it would be a shame to put significant resources towards an integration which isn’t ‘top of the line’ anymore.

Just my two cents, albeit not what people may want to hear.


Yes, I agree, we are going to provide this soon.

Yes, I also agree, in the long term a transition to Capacitor is something to consider as it supports Cordova plugins, the main goal would be to improve our DX without losing compatibility with existent applications. We always need to keep mind that Meteor is used by many companies to deliver native apps and we don’t want to force anybody to rewrite their apps, we need to do our best to keep things working, but a possible Capacitor transition in the future could be done in a smooth way I think but I would need to understand and test this more.

My two cents about next steps:
Update Cordova version and fix any existent issue.

BTW, I have some native apps published with Meteor then for sure the integration is not broken right now but could be in a better state and with better docs.


I agree. If Meteor can expose hooks that allow other native/mobile app development frameworks to plugin to the CLI and build process to enable a similar integration then we can spin off Cordova integration outside of the Meteor core allowing for faster bugfixes and updates.


This is great news from my perspective, I was kind of worried that the Cordova integration would fall by the wayside. But if that is kept up to date and is a viable option for building a cross platform application that is a tangible benefit to Tiny taking control of the Meteor project. One of the biggest selling points to me about Meteor was the ability to build mobile applications so I am excited about this announcement

And if Capacitor takes off and becomes the Cordova of the future I agree that its a good plan to switch from Cordova to Capacitor if and when that day comes. Thanks for all the updates @filipenevola


Agree 100% on the need for a reference implementation. Cordova can be done very right, or very very wrong. Users shouldn’t be able to tell that it’s not native so an implementation that is performant (snappy, conscious of CPU usage) and built with a native-mimicking framework like ionic would be a great start to show people that it can be done right. If you just say “Cordova integration” I know a lot of ppl who won’t even consider it because it gets a bad reputation for clunky and slow apps.


100% this, I would like to see the build system decoupled and more of an opt-in, think of Meteor <- Middleware -> Framework (cordova, reactive native)

Some of these have been on my wishlist since pre-1.0:

  1. Decoupling the build system
  2. Support Engines/Middleware apps (think Rails Engines / Elixir Umbrella Apps, etc), where in a Meteor application can mount other Meteor applications
  3. The package system should die out, and an NPM-based replacement put into place

Thanks for being so communicative and transparent on all this. Really appreciate it!

I’m currently using meteor-imports-webpack-plugin to integrate with Svelte-Native. It works pretty well so far (caveat: I am not that far in to it). It allows me to pull in meteor packages, and other assets defined in my meteor app, without having to use a lot of re-implemented alternative ddp connectors. Perhaps this is the way to integrate with third party build systems? It should work for Cordova or React Native, with a similar set up.

Once I have more proof of concept pulled together (looking to get at least some login stuff working), I’ll post a starter.


These have been mentioned above but I will just add my reasons why I supported the decoupling of cordova integration from meteor core

  1. Major reason was the resources allotted to maintain meteor core was not enough to do other stuff like maintaining the cordova integration. I believe the community is more than willing enough to help keeping the cordova integration up to date

  2. And talking about keeping it up to date, I think we are two major versions behind.

  3. There is this ongoing issue with Apple potentially blocking apps with the old webview engine and this is currently being solved by cordova. This potentially means a new version and I am not sure how fast we can use it

  4. And there are other frameworks and libraries out there that are compelling alternatives with cordova eg. capacitor, react-native, etc

If Tiny, can help with 1, 2, and 3 above, then that is good. #4 will be amazing

1 Like

Ugh, the idea of Meteor apps deployed on mobile devices sounds like a dream :slight_smile:
I really hope you guys could make this happen in a way robust enough for us to use on production.

1 Like

Many of us have been doing this for years, and it is a dream! One UI code-base to rule them all.

We just hope we can continue without having to re-write our apps, and that’s looking promising!