There are several benefits with being able to hot code push updates for your app to users without having to wait for their acceptance or manual intervention. One major benefit is that it makes it possible to instantly patch critical bugs which an app may have; another that it makes it possible to ensure that the app and the backend is always in sync. That is, you do not need to maintain indefinite backward compatibility in your app backend.

This is likely the most significant benefit to most organizations. Maintaining backward compatibility is complicated; and the complexity grows with the number of deployed versions of the system. One huge benefits of a traditional web based system is that of complete version synchronization between client and backend. With native mobile app systems this is most often not the case and the released versions of the apps can lag behind the version of the deployed backend.

But by ensuring that all instances of the mobile app is running the latest software we can avoid the requirement of constant backward compatibility, and thereby reduce the complexity and cost of the overall system.

Native mobile application do not offer a simple way to perform hot code updates. More importantly the iOS platform explicitly forbids it as seen in section 3.3.2 of their iOS Developer Program License Agreement (you have to be enrolled to be able to read it). But the same section in the License Agreement apparently allows hybrid applications to fetch code changes, as long as these changes do not change the character of the app and the code is run in a web view (which it is in the case ionic/cordova).

Since hybrid applications are run in a web view, simply a wrapped browser, it means that a hybrid app code could just as easily have been severed by a web server. This property is what needs to be utilized when creating a hot code push system.

I have created an example application here. The application is based on cordova/ionic and showcases a technique that allow us to push code updates to an already installed app automatically without requiring the user to accept the update. Granted, it only does so for Android (I do not own a Mac), but it should work in iOS with minimal modifications. The “push” is actually not initiated by the server, but rather each time the application is started it will actively check for updates against a remote server. This is performed by utilizing a HTML5 feature called application cache. The first thing the application does at initialization is to try and download a copy of the application cache manifest. The downloaded copy of the manifest is compared against the already stored version. If any changes are detected all the application resources(html, css and javascript) are downloaded from the remote server. If the application is unable to get a hold of the remote cache manifest then the cached version of the app will be used(html, css and javascript will be loaded from a local storage).

What this means is that the application, once loaded the first time, will keep working even though the terminal lacks network connectivity. The idea is simple, but there are a few quirks with the application cache specification which requires us to take some extra precautions. A HTML5 application which utilizes application cache will always load the resources from the cache first, and then update its cache with the newly downloaded versions of the resources if they are available. But it will not automatically reload the page with the fresh version of the application. This requires us to listen to cache events that tells us about the availability of a new version of the resources, and manually force an update by reloading the site, like so:

window.addEventListener('load', function(e) {
        if (window.applicationCache) {
            window.applicationCache.addEventListener('updateready', function(e) {
                if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
                    // Browser downloaded a new app cache, apply it
                    window.applicationCache.swapCache();
                    window.location.reload();
                } else {
                    // Manifest has not changed changed
                }
            }, false);
        }
    }, false);

Another thing which is a bit surprising is that the application cache really does not look for changes in the resources, but rather only for changes to the cache manifest. Therefore it is important to make sure to update the cache manifest across versions. It is sufficient to update a comment line if no files have been added or deleted.

Furthermore it is important to make sure that all the files listed in the cache manifest is actually available for download. If they are not, the caching process will terminate with an error and the script execution on the site will fail.

Other than that the implementation is very straight forward. If this was to be used in production some further precautions are likely needed. Maybe bundling a first version with the app bundle if the user does not have network access the first time the app is opened. This would prevent the ugly network failure page which is otherwise the result.

It is probably also a good idea to manage the transition between app versions a bit more gracefully than the method displayed in the github demo (which is simply reloading the app without notifying the user).

But as you can see it is absolutely possible to perform hot code updates in hybrid application with what is as hand today. If anyone have examples of this being done live based on open source software I would be very interested to hear about your experiences!