For up-to-date product documentation, see the IBM MobileFirst Foundation Developer Center.

Updating Cordova client apps directly

With direct updates, you deliver updated web resources directly to deployed client applications.

Subject to the terms and conditions of the target platform, organizations are not required to upload new app versions to the app store or market. By using the Direct Update feature, we can quickly update application web resources (HTML, JavaScript, and CSS) without going through the vendor (Apple/Google) app store review process.

Direct Update is activated automatically when web resources are deployed in the MobileFirst Server. Once activated, it will be enforced on every request to a protected resource. When we use the Direct Update feature and the web resources checksum feature is enabled, a new checksum base is established with each Direct Update.

Direct Update is not intended for updating native code.

Supported platforms

Direct Update is available only for iOS and Android Cordova apps.


If the MobileFirst Server was upgraded by using a fix pack, it continues to serve direct updates properly. However, if a recently built Direct Update archive (.zip file) is uploaded, it can halt updates to older clients. The reason is that the archive contains the version of the cordova-plugin-mfp plug-in. Before it serves that archive to a mobile client, the server compares the client version with the plug-in version. If both versions are close enough (meaning that the three most significant digits are identical), Direct Update occurs normally. Otherwise, MobileFirst Server silently skips the update. One solution for the version mismatch is to download the cordova-plugin-mfp with the same version as the one in your original Cordova project and regenerate the Direct Update archive.

Incremental and full Direct Update

Client applications built on IBM MobileFirstâ„¢ Platform Foundation V8.0.0:

Secure and non-secure Direct Update

For secure Direct Update to work, deploy a user-defined keystore file in MobileFirst Server and include a copy of the matching public key in the client application. If the client is not configured with a public key, MobileFirst Server uses the default server keystore to sign Direct Update but does not enforce signature matching.

If secure Direct Update was enabled and the archive signature was compromised, the client halts the update. Failures such as these are reported in the server logs.

Note: Failures such as these might also prevent correct adapter invocation.

For more information about implementing secure Direct Update, see Implementing secure Direct Update on the client side.

Direct Update in development, testing, and production

For development and testing purposes, developers typically use Direct Update by simply uploading an archive to the development server. While this process is easy to implement, it is not very secure. For this phase, an internal RSA key pair that is extracted from an embedded MobileFirst self-signed certificate is used.

For the phases of live production or even pre-production testing, however, it is strongly recommended to implement secure Direct Update before you publish your application to the app store. Secure Direct Update requires an RSA key pair that is extracted from a real CA signed server certificate.

To implement secure Direct Update, deploy a user-defined keystore to the MobileFirst Server and copy the matching public key to the client application. For more information about implementing secure Direct Update, see Implementing secure Direct Update on the client side.

Note: Take care that you do not modify the keystore configuration after the application was published, updates that are downloaded can no longer be authenticated without reconfiguring the application with a new public key and republishing the application. Without performing these two steps, Direct Update fails on the client.

For more information, see The Direct Update lifecycle.

Direct Update data transfer rates

At optimal conditions, a single MobileFirst Server can push data to clients at the rate of 250 MB per second. If higher rates are required, consider a cluster or a CDN service.

For more information, see Serving Direct Update requests from a CDN.

Parent topic: Developing applications