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

Update MobileFirst apps in production

There are general guidelines for upgrading your MobileFirst apps when they are already in production, on the Application Center or in app stores.

When we upgrade an app, we can deploy a new app version and leave the old version working, or deploy a new app version and block the old version. In the case of an app developed with Apache Cordova, we can also consider only updating the Web resources.

Deploy a new app version and leaving the old version working

The most common upgrade path, used when you introduce new features or modify native code, is to release a new version of your app. Consider following these steps:

1. Increment the app version number.
2. Build and test your application. For more information, see Build an application for a test or production environment
3. Register the app to MobileFirst Server and configure it.
4. Submit the new .apk, .ipa, .appx, or .xap files to their respective app stores.
5. Wait for review and approval, and for the apps to become available.
6. Optional - send notification message to users of the old version, announcing the new version. See Displaying an administrator message and Defining administrator messages in multiple languages.

Deploy a new app version and blocking the old version

This upgrade path is used when we want to force users to upgrade to the new version, and block their access to the old version. Consider following these steps:

1. Optional - send notification message to users of the old version, announcing a mandatory update in a few days. See Displaying an administrator message and Defining administrator messages in multiple languages.
2. Increment the app version number.
3. Build and test your application. For more information, see Build an application for a test or production environment
4. Register the app to MobileFirst Server and configure it.
5. Submit the new .apk, .ipa, .appx, or .xap files to their respective app stores.
6. Wait for review and approval, and for the apps to become available.
7. Copy links to the new app version.
8. Block the old version of the app in MobileFirst Operations Console, supplying a message and link to the new version. See Remotely disabling application access to protected resources.

Note: If you disable the old app, it is no longer able to communicate with MobileFirst Server. Users can still start the app and work with it offline unless you force a server connection on app startup.

Direct Update (no native code changes)

Direct Update is a mandatory upgrade mechanism used to deploy fast fixes to a production app. When you redeploy an app to MobileFirst Server without changing its version, MobileFirst Server directly pushes the updated web resources to the device when the user connects to the server. It does not push updated native code. Things to keep in mind when you consider a Direct Update include:

• Direct Update does not update the app version. The app remains at the same version, but with a different set of web resources. The unchanged version number can introduce confusion if used for the wrong purpose
• Direct Update also does not go through the app store review process because it is technically not a new release. This should not be abused because vendors can become displeased if you deploy a whole new version of your app that bypasses their review. It is your responsibility to read each store's usage agreements and abide by them. Direct Update is best used to fix urgent issues that cannot wait for several days.
• Direct Update is considered a security mechanism, and therefore it is mandatory, not optional. When we initiate the Direct Update, all users must update their app to be able to use it.
• Direct Update does not work if an application is compiled (built) with a different version of IBM MobileFirst Platform Foundation than the one that was used for the initial deployment.

Parent topic: Deploy MobileFirst applications to test and production environments