Confused about meteor+cordova

As far as I understand, a meteor app has two parts:

  • a client-side written using a front-end framework for the UI (which is non-meteor code unless Blaze is used as front-end framework) plus meteor subscriptions and method calls to communicate with the server;
  • a server-side with the meteor collections, publications and method definitions.

I thus assume that:

  • whether subscriptions and method calls run in web browser or a in web view makes no significant difference since their sole purpose is updating data from/to the server;
  • all the usage of the mobile device resources available through Cordova plug-ins that is not accessible from a browser is located in the front-end framework part of the code, not in the Meteor part of the code.

Therefore I am confused as to whether the Meteor-Cordova integration is only needed when using Blaze as a front-end or whether it is also needed when using Vue, React or Angular as front-end even though they seem to all have their own independent integration with Cordova.

In particular, I assume that if one uses the Meteor Client Bundler to leverage the Meteor client-server DDP communication API but build the client-side with a front-end framework build tool instead of the Meteor build tool, then one could deploy an hybrid app using only a Cordova plug-in for whatever front-end framework is used for the client-side code without the need of the Meteor-Cordova integration. Is that correct?


Cordova is a concept/principle and a bunch of tech.
Meteor builds a separate client for Cordova (Meteor.isClient (web and cordova) Meteor.isCordova (only cordova clients).
Your code, regardless of the Front-end might need some changes. Examples:

  • You sometimes needs to control what starts first, some Cordova plugin or Meteor.
  • Adopt more of the native design of either IOS or Android by integrating with the nativ UX via Cordova plugins.
  • Use native maps instead of your usual Google web embeds.
  • Use a design/styling library that helps you get closer to mobile design principles.

To answer your matter, you need Cordova to build a mobile app for the store or for “internal” distribution. You can use anything for your front-end, Cordova will be running your webapp in a small web server on the mobile device.

1 Like

Thank you very much for your answer. From it I now infer that I may have misconceived what constitutes a Meteor-Cordova hybrid mobile app. I thought it was a multi-user application distributed over the internet with the server-side code running on a remote, high capacity, non-mobile server machine and only the client-side code running on the mobile device in a web view and with access, though Cordova plug-ins, to resources not available from a web browser.

But perhaps such multi-user distributed application does not qualify as a hybrid mobile app but rather as a Progressive Web App? And then a Meteor-Cordova hybrid mobile app is in fact a single-user stand alone app with no remote communication over the internet and which encapsulates a web server and a MongoDB DBMS both running locally on the mobile device to execute the server-side code of the Meteor app also locally on the mobile device?

If this is the case, isn’t using Meteor, which unique strength is automated change propagation among multiple users sharing a common DB, for a single-user, stand-alone app an overkilling approach?

Thanks in advance for helping my grasping of what precisely is and is not a Meteor-Cordova hybrid mobile app.

Nope :).

I think this Plugin explains it in details: cordova-plugin-meteor-webapp - npm

With Cordova you generate what otherwise you would build with React Native, Ionic, XCode, Android Studio etc … namely, mobile apps for the store, apps which are more or less “native”.
Write in Swift and build in XCode would give a fully native App. React Native would produce a native compiled app (compiled from JS to the native languages). Ionic (which is Cordova) would produce a JS bundle similar to an HTML SPA that runs on a JS server inside Cordova, inside some native code. We call it hybrid because you have JS running inside “native”.

PWA - the way you run your web app in a browser. You add some HTML tags, a web worker eventually and now you have more than a WA, you have a PWA. This has no similarities with Cordova.

“Meteor-Cordova hybrid mobile app” is “client-side code running on the mobile device in a web view and with access, though Cordova plug-ins, to resources (mobile hardware mainly) not available from a web browser.”
The word “hybrid” applies to how the Play Store, or Apple Store app was build, as mentioned above, whether natively, compiled or with JS running inside native (Cordova).

Thank again, but alas I am getting more and more confused.

That I understand.

Nope to all three of my questions? or only to the first?

OK so it starts with:

Cordova apps don’t load web content over the network, but rely on locally stored HTML, CSS, JavaScript code and other assets.

From this I gather that a Cordova app, whether it uses Meteor or not, is a single-user stand alone app storing all data locally and accessing the internet only for updates.

But then you say:

which makes me conclude that the web server and MongoDB DBMS that run the server-side code of the Meteor-Cordova app (collections, subscriptions and methods definitions) do run on a real remote server machine and not locally on the mobile device.

So where does the server-side of a Meteor-Cordova app actually runs:

  • locally on the mobile device where a Node.js web server and MongoDB DBMS are installed?
  • or remotely on a real server machine?


That says “don’t load web content over the network, but rely on locally stored HTML, CSS, JavaScript code and other assets.” Data and bundle updates is what comes from your Meteor server.

ok, you have a server infrastructure with 1 Meteor Server or more and you can have multiple clients:

  1. Native Apps
  2. Hybrid apps (Cordov)
  3. Web apps (browser)
  4. Power Web Apps (browser)
  5. no apps (server only)

I am not sure where you get confused. With Cordova you don’t open a browser and get HTML, CSS, JS from a server. Everything is already in your App as published in the store. HTML, CSS and JS are ran into an internal web server in your mobile app. Your app connects to a Meteor server to get the data.

Thank you very much.

This is what I now gather:

A mobile app (whether hybrid or native) can be either:
a) a single-user stand-alone app storing all its persistent data locally and not including any networking communication;
b) the front-end half of a multi-user distributed client-server app fetching/persisting data from/to a remote server machine using some networking protocol (HTTP, DDP, etc.).

In the second case, the main difference with a web app is that the front-end half does not run in a web browser but either on the extended JS platform provided by a web view + the Cordova (or Capacitor) plug-ins (hybrid mobile app) or on the native platform provided by the mobile device (Swift for iOS and Java for Android, native mobile app).

So I guess the next question is, in the case of using for the Meteor app, a front-end framework that features its own build tool and Cordova plug-in:

  • Is the Meteor-Cordova plug-in only needed for hot code push updates of the Meteor version?
  • Or is it also needed for exchanging data through DDP between the minimongo front-end collection cache and the remotely persistent back-end collections (i.e., so that the under the hood Meteor framework code implementing Meteor method calls works properly on the mobile device).


In the time, you spent asking those questions you could have easily built a Meteor Cordova App and seen for yourself (assuming you don’t have to install Android Studio first, that can really suck…). :wink:

You can build a Cordova App with a different build system, but then you have to rely on a standalone ddp client library, and AFAIK none of those includes Minimongo. So if you want to use Pub/Sub you will have to deal with all the updates yourself.

When you stick with Meteor as a build system for the Cordova App you also gain some flexibility. You may just start developing a responsive-design web app and then turn that into a Cordova app later on if you need some native functionality and find it worth the trouble of going through the app stores (and deal with Android Studio, did I mention that getting it to run can really suck?).

Apart from the problems some cordova plugins may cause (but that won’t be better with other build systems), that’s really easily done with Meteor. Just type meteor add-platform ios wait for meteor to do some setup and then meteor run ios and you are ready to test in on the iOS emulator (assuming you have Xcode installed, wich is really easy to do).

So if you use Meteor for the backend anyway, I can’t think of a good reason to not build the Cordova app with it, too.

On a side note: You can load html, css and js from the server in a cordova app. There are quite a few cordova apps out there that just display a frigging php web-site. But that’s really, really bad (and quite often leads to 1-star ratings with really harsh reviews that question the professional integrity of the developers).