Meteor hot code push — with great power comes great responsibility

Out of the box, Meteor comes with an amazing ability called ‘hot code push’. Hot code push lets you update all of your connected clients, browsers and mobile apps when the server is updated, without going through any app reviews. It’s the dream of every mobile developer who has waited 14 days to update their iOS app through Apple’s app store. But with this awesome power comes great responsibility. If handled incorrectly, hot code push can cause user experience issues in your app, like a reload of the app when the user doesn’t expect it.

Here are some best practices and tips for working with Meteor’s hot code push:

1. Release to the App Store as often as possible. When a Meteor PhoneGap application starts, it first runs the code shipped through the App Store or Play Store and then checks for an update from the server. If there is an updated version, it is being downloaded to application’s internal storage and then the app reloads. If the initial code shipped by the App Stores is up to date, we can prevent that process from our users.

2. If you need to push new code fast, you can control when the app reloads with the help of the mdg:reload-on-resume package. The package will apply the update only when the user closes the app and reopens it again, without interrupting the user in the middle of his work.

3. To avoid slowing down your local development process with the reload on resume package, you can use the arsnebula:appupdate community package so you can still use the regular instant hot code push while developing your app locally.

4. Remember, you still need to handle breaking changes very carefully. Even after you have pushed a new update, there might be users who are running older versions of your code with different routes or schemas. So when introducing breaking changes to your schema, routes, and methods, keep in mind that you might need to support both versions of the frontend code until all users migrate.

5. Remember, Cordova plugins are not updated by hot code push so you will need to update your store listings in order to use the new cordova plugins. You will need to be aware of this when writing your code, and add conditionals to detect if the user has the new plugins installed.

6. To make mobile hot code push faster, try to limit the size of files in your project. Meteor pushes all files in the app’s client folder to the mobile device, so if you have a web app, landing page, or admin dashboard on the same meteor app, you should try to separate those into different packages where can control whether the files are built for the web browser, Cordova, or both.

7. Last but not least, you should know about nucleuside:live-update, which lets you hot code push specific files without reloading the whole app.

Now you are ready to master the Hot Code Push magic! Meteor 1.2 will introduce a lot of improvements to the Cordova integration, so this workflow is going to get even better soon.

Comments

[Michael Lee]

Helpful article, Uri - thanks for publishing it. Question for you: my colleagues and I were regression testing a Meteor app we plan to release in beta quite soon, and while we were testing I was patching issues and deploying (Nodechef is our hosting provider, if that matters). Over the hour we tested, I patched and deployed 4 times.

Strangely, on one or two of the hot code pushes, users were not able to complete any actions. No errors in the browser console nor server. When they reloaded the page they were on (all browser based testing, no Cordova app yet), it turned out they were logged out. No code was pushed to cause that and by default they're logged in for quite a long time.

Is there anything in a hot code push that would cause users to be unauthenticated? I made a change to the publications and a server method call and have been scratching my head as to whether server-side files being modified will invalidate existing authentication sessions.