I developed an app which I wan’t to deploy as a mobile app as well. Therefore I’m running the app on my device using the command meteor run android-device...
The build process then needs almost 10 minutes before I can test the app on my phone because all the plugins and everything had to be rebuild on every change I made.
Since I’m working with plugins I have to do the tests on my phone but with this build time it is almost impossible to make progress and that is relly frustrating.
So I’m wondering if there is any posibillity to speed this up. How do you guys test your cordova apps?
Isn’t hot code push working for you? Apart from adding or removing plugins, most changes shouldn’t require a rebuild.
Having said that, a build time of 10 minutes is really long. Are you using any plugins from the local file system? That will be significantly slower because all plugins will be added and removed on every build. Cordova should cache plugins downloaded from npm, but will redownload plugins from Git.
Are you using Meteor 1.2 or 1.3 beta?
Thanks for your answer. I updated to the newest beta and finally got hot code push working. Now it is only 45 seconds for rebuilding the app which is way better 
Hi. Jumping in here: I too am going slightly mad with the build times over here.
You’re right in that the hot code push takes the pain away when everything is running, but there are sometimes reasons that it’s required to build newer Versions to try out different things depending on the cordova build.
Every time I run into this kind of situation it sure is a productivity killer.
These are moments when I need to rebuild the app:
- IP Address changes because I’m in a different Wireless Network
- Adding / Changing Cordova Plugins, of course
- Experimenting with mobile-config.js
- EVERY TIME I’VE GOT CONNECTION PROBLEMS WITH THE APP because of some issue - even if it’s only a JS issue - because then the only way to fix the issue / test out what causes the issue is to build a new Version for the App
- Actually every time I manage to push some broken JS Code to the app which prevents proper startup of the app - because sometimes I manage to do that and need to debug the issue using trial-and-error / binary-searching through the changes we did since the last working version. This of course becomes lots more fun if you manage to put in two separate issues which both prevent server connections in some way or another (Yes, i’m looking at you, FORCE-SSL!
) - Having forgotten / removed the cordova device by accident or disconnected it somehow
- Having a version clash / some issue with the deployment on the phone
- Having to try this on both ios and android in many cases, meaning having to test and possibly re-test / build the entire app twice
- And, of course, the ever dreaded “Error: Error parsing asset manifest(…)” - message in the console which seems to hint that a reinstall (which means rebuilding for local development) is required to get back to a working state.
That are only a few of the things which can cause productivity to grind to a halt if there’s trouble with the cordova integration.
Actually I wrote this whole post During one Build and launch and it just gut finished and I can have a look at the next feature i’m gonna be working on.
The whole ordeal took, no joke, about 13 minutes from start to actually running on the phone. I timed it on the command line:
~/projects/DDD/meteor/topsecret/code (develop)> date
date
Di 26 Apr 2016 17:15:53 CEST
~/projects/DDD/meteor/topsecret/code (develop)> date
Di 26 Apr 2016 17:28:25 CEST
Not to mention that I had to do it twice because I had another version installed which apparently had the same or a newer version number, which isn’t meteors fault, but which, together with the long build time, made me type out this post now.
This is a bigger project with 5 cordova-plugins at the moment. I’m working on a Macbook Pro with a Quad-Core i7 CPU, 16 GB Ram and an SSD Hard Drive.
Actually the whole rant here isn’t entirely fair, because on top of everything else we seem to have to nuke the entire build before every new build at the moment, because of a cordova issue where it shows us an error “Cordova error: Cannot find plugin.xml for plugin ‘cordova-plugin-compat’. Please try adding it again.”, which I suspect may be the fault of one of our cordova plugins. But at the moment I dread debugging which one because of the turnaround times involved at the moment…
SOOOO anyways, we’re having an issue where working on cordova-critical parts of the app REALLY slows down our turnaround time, and it’s also really hard to stay on track developing / debugging this way, because it’s hard to keep your debugging or development - process in mind all the time over these long delays and also because you can only explore a handful of different options per hour, which of course isn’t a lot of experiments to go on while debugging / developing.
So if there’s any way to speed this up, it’d still be a great boon for us.
Still, I’d like to take the edge off a bit here: The updates to the Cordova - Integration with Meteor 1.3 are amazing and at the whole everything about Meteor is of course delightful. This is just one pain point i wanted to express to allow us to make the whole thing even better! Thanks to Martijn and the whole Team of course.
1 Like
Wow, that seems insane. I can imagine development, with build speeds like that, is incredibly infuriating.
I’m sorry I can’t help. We have a production application which has iOS and android apps… I found mobile issues with meteor@1.2, but upgrading to meteor@1.3.x.x fixed all our issues (non of them were particularly deep issues). The only issue now is some cordova plugins that require a higher node version than meteor uses. But we have found workarounds to that i.e. just writing plugins ourselves.
Do you have long build times after the initial build, or is it just the first build that runs slow? I think our builds average out somewhere between 14 to 20 seconds on an i7. After which the updated app is available on the device or emulator.
1 Like
Hi Daniel,
I’m experiencing the same problems as you. A new build of my app after a meteor reset literally takes ages (sometimes up to 25 minutes). This is caused by Meteor downloading all Cordova plugins again - which in my case is very slow, due to my very low download rates from Github.
This is also one of the main reasons why I have to re-build the whole app very often. Did you happen to solve this problem? I’ve just opened a new thread on the same problem, before I found your message:
Hi @waldgeist,
I noticed that the error went away after updating (most) of our cordova plugins to the latest version available on NPM. We still get similar warnings, but no error cancelling the build anymore.
1 Like
I think I found the root cause for this:
Hello Waldgeist,
i’m a bit late but I still wanted to thank you for your support in these hard times I had!
Actually I have also found out that I’m probably the victim of a slower Notebook here. I THOUGHT it shoud be good (Quad-Core i7, 16 Gigs ram, SSD…), but I recently saw another project of mine building on a colleagues’ Macbook Retina from last year (still the newest at the moment) and HOLY COW did it fly through the build… probably 10 times faster, no doubt.
Sooo… i’m waiting for the new Macbooks to come out in june hopefully and then I’ll give myself the boost!
Just a heads-up for all the devs which might stumble across this, build times, especially cordova build times, can be greatly shortened with fast hardware. Who’d have thought.
I also found out that “the ever dreaded “Error: Error parsing asset manifest(…)” - message in the console” which I cited in my post - turns out that there’s some cordova-serving component to meteor which only gets activated when you run meteor run android-device or ios-device or one of the other mobile platform targets. Adding --mobile-server=myip:3000 isn’t enough to trigger it, that’s what caused the error.
It should get fixed in one of the next minor updates if it hasn’t already though I think. I just wanted to leave it here in case somebody stumbles over this post - now you know!
KThxBy and don’t come spooking to my home Mr @waldgeist!
1 Like
Thx for your kind words 
Nope, I’ll stick to the forests 
I wanted to post my solution to reducing long build times specifically around using forked plugins. It’s fairly specific, but it may help someone else experiencing this.
Similar to the issue that @martijnwalraven mentioned with local plugins, Cordova redownloads forked plugins from Git, or Bitbucket, as is the case for the google maps SDK, every time because they’re not coming from NPM and thus are not cached, which is really painful.
We’re using a few plugins that we had to fork: google-maps cordova plugin (which in turn downloads the google maps SDK), crosswalk and a few others that weren’t really contributing to the slowdown.
The fix was to manually clone each of these repos locally and then use a Git config url insteadOf entry for each one of those, which tells Git to use the local repo instead of going out to the URL. Here’s an example:
[url "/localpath/cordova-plugin-googlemaps"]
insteadOf = https://github.com/37d/cordova-plugin-googlemaps.git
This reduced our build time from 10-15 minutes+ to about 2 minutes so this was an enormous improvement for us.
1 Like