Updating 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.

The general procedure for deploying your MobileFirst apps for the first time to MobileFirst Server and the Application Center is as follows (see Deploying an application from development to a test or production environment).
  1. Build and test your app by using IBM MobileFirst™ Platform Foundation, and use either the MobileFirst Operations Console or the supplied Ant tasks to deploy its .wlapp files to MobileFirst Server and the Application Center.
  2. Submit the generated device app files Application Center: .apk for Android apps, .ipa for iOS apps, .appx for Windows 8 Universal app, and .xap for Windows Phone 8 Silverlight app) to their respective app stores: Google Play, Apple Store, Windows Store, and Windows Phone Store.
  3. Wait for the completion of the review and approval process. Try to avoid updating your app before the review process is completed because doing so can trigger a Direct Update and can confuse the reviewers.
Procedures for upgrading your app when it is already in production are contained in this section. You can choose from several ways to perform such upgrades, depending on their nature:
  • Is the upgrade a new version of the app that contains new features or native code, or is it a bug fix or security upgrade?
  • Is the upgrade mandatory or optional?
  • If it is optional, do you want to leave the old version of the app in place and available to users, or not?
  • How and when do you want to notify users of the upgrade?
These subjects are covered in the following topics.

Deploying 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 project and generate new .wlapp, .apk, .ipa, .appx, or .xap files for it.
  3. Deploy the new .wlapp files to MobileFirst Server.
  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 a notification message on application startup and Defining administrator messages from MobileFirst Operations Console in multiple languages.

Deploying a new app version and blocking the old version

This upgrade path is used when you 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 a notification message on application startup and Defining administrator messages from MobileFirst Operations Console in multiple languages.
  2. Increment the app version number.
  3. Build and test your project and generate new .wlapp, .apk, .ipa, .appx, or .xap files for it.
  4. Deploy the new .wlapp files to MobileFirst Server.
  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 Locking an application and Remotely disabling application connectivity.
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 that is 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 you 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.
The steps for initiating a Direct Update are as follows:
  1. Optional - send notification message to users of the old version, announcing a mandatory update in the next few hours or days. See Displaying a notification message on application startup or Defining administrator messages from MobileFirst Operations Console in multiple languages.
    Note: Do not increment the app version number.
  2. Build and test your project and generate new .wlapp files for it.
  3. Deploy the new .wlapp files to MobileFirst Server. This initiates the Direct Update.
For more information about Direct Update, see Direct updates of app versions to mobile devices.

Application authenticity

This feature will not work properly for clients that were built with an older version of IBM MobileFirst Platform Foundation when the application deployed is of a new product version but has the same application version. Those client requests to access the authenticity-protected resources will be denied.

To keep support of old applications using app authenticity, or block them, follow these steps:
  1. Upgrade the project by using the newer version of IBM MobileFirst Platform Foundation, as described above.
  2. Increment the versions of the upgraded applications.
  3. Deploy the new WAR file that was built.
  4. Deploy the new applications to the server alongside the applications that were built with the old IBM MobileFirst Platform Foundation.
  5. Normally, both applications work as expected. If you want to use the new ones only, block the old ones and refer to the new ones for upgrade.
For more information about application authenticity, see MobileFirst application authenticity overview.
Parent topic: Deploying MobileFirst applications to test and production environments