I’m really worried about breaking changes upgrading from 1.2. In the release notes there’s a vague mention that “plugin used to serve your app’s files and support hot code push has been completely rewritten”… what are the actual tangible benefits?
(I know I want to upgrade eventually, but right now there’s competing priorities)
From the the official Meteor 1.3 release announcement:
Meteor 1.3 comes with a completely rewritten Cordova layer for building iOS and Android applications in Meteor. New, robust iOS and Android wrappers detect and handle faulty JavaScript application code. It is now possible to recover from hot code pushes of broken code that previously required an application reinstall. The hot code push system is also much faster and uses incremental and resumable updates to save network bandwidth and battery life. Meteor 1.3 includes support for WKWebView on iOS (including iOS 8), which dramatically improves application performance and frame rates. Finally, Cordova has been upgraded to the latest versions (Cordova 6.0.0, Cordova iOS 4.1.0, Android 5.1.1)
So faster, safer, easier to use, and more up to date. Sounds like a good time to upgrade! 
As mentioned, the new Hot Code push system is much more stable and the use of WKWebView means in almost all apps you will get better performance (on ios). That said if you have a stable mature application and your users are not shouting at you to solve the problems 1.3 solves, i would not upgrade.
Instead I would factor the upgrade in to your next development cycle, its worth mentioning that you will also have to redeploy your app (AppStore) to make use of these features as the new Hot Code push system is native code, users don’t like updating apps (especially when no new features exist)
Thanks, I didn’t see that full text. It sounds more tempting as I have had customer complaints re white screens during hot code push.
@floydprice thanks for your point about change of iOS native code - that really wasn’t clear to me before. Sets off alarm bells… does that mean that after I’ve deployed my shiney new 1.3 server code, my iOS clients will not be able to hot code push until they have updated from the app store? Which means I would have to support multiple client versions for an extended period of time?
(I know that in theory we have to support multiple client versions now, but in practice only for less than 1 min of use before hot code push is forced on the client.)
I have not tested all the scenarios, but from my tests any 1.3 updates wont get delivered to a device running 1.2. (not sure what the official line is here, or if there even is one) Like anything your milage may vary, if your compelled to update (sounds like you might be) i’d create a branch, upgrade to 1.3 and deploy in a staging env to test the migration process on your devices.
@floydprice thanks for your foresight, you were right and it seems to be causing something of a problem to these guys: Cordova app (Android) not reloading after hot code push with deployed app
I am going to be very cautious around this update as I have thousands of live cordova clients out in the wild. Do you know a way I could reliably pop up a dialog box to older client versions to ask the user to update via their app store?
Hey @alveoli
Yeah its a tricky one! I have not had to actually had to execute on this but conceptually i have a solution in mind.
You basically need to maintain an 1.2 version of your “app” and a 1.3 version (so different end points) for a little while, upgrade and republish a new major version of your cordova app (on 1.3), so anyone who is proactive about app updates will move to the new platform.
Then for anyone who doesn’t update you can add a nag screen to your 1.2 code base which will be hot deployed to them, the nag screen will prompt them to upgrade (make it annoying so that it forces the to take action)… Once they all have upgraded you can decommission the 1.2 implementation completely.
This (clearly) isn’t the only solution and depending on your app and your customer base it might not be the most appropriate but for me (conceptually at least) it works pretty well.
All the best
Floyd
Hi @floydprice
I like the concept, and I guess it’s the ‘traditional’ migration route when we used to have those old things called APIs 
… in the Meteor world I’m not sure about the details of how it would translate - e.g. how would you set different end points for DPP etc. And a bit frightened of the consequences to be honest…!
What do you think of a simpler (but more restrictive) hack:
Push out a 1.2 version that checks the server’s version number. If it’s above a pre-set, hardcoded value, display an upgrade prompt (maybe even time-bomb to stop it working after x months). Wait a while, then upgrade to 1.3.
Then I’m left with 3 questions:
Alvin