Update MobileFirst apps in production

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

Deploy the MobileFirst apps for the first time to MobileFirst Server and the Application Center is covered in other sections of the information center, such as Deploy apps from dev to test and prod. To recap, the general procedure is as follows:

• Build and test the app using MPF, and use either the operations console or the supplied Ant tasks to deploy its .wlapp file to MobileFirst Server and the Application Center.

• Submit the generated device app files (such as .apk for Android apps and .ipa for iOS apps) to their respective app stores (in this example, Google Play and Apple Store).

• Wait for the completion of the review and approval process. Try to avoid updating the app before the review process is completed because doing so can trigger a Direct Update and can confuse the reviewers.

Procedures for upgrading the app when it is already in production are contained in this section. There are several ways to perform such upgrades, depending on their nature:

• Is the upgrade a new version of the app containing 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 to leave the old version of the app in place and available to users, or not?

• How and when do to notify users of the upgrade?

These subjects are covered in the following topics.

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 the app. Consider following these steps:

1. Increment the app version number.

2. Build and test the project and generate new .wlapp, .apk, and .ipa files for it.

3. Deploy the new .wlapp file to MobileFirst Server.

4. Submit the new .apk or .ipa 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 operations console in multiple languages.

Deploy a new app version and blocking the old version

This upgrade path is used when 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 operations console in multiple languages.

2. Increment the app version number.

3. Build and test the project and generate new .wlapp, .apk, and .ipa files for it.

4. Deploy the new .wlapp file to MobileFirst Server.

5. Submit the new .apk or .ipa 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 operations console, supplying a message and link to the new version. See Lock an application and Remotely disabling application connectivity.

If we 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 the app that bypasses their review. It is the 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 MPF 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 operations console in multiple languages.

   Do not increment the app version number.

2. Build and test the project and generate a new .wlapp file for it.

3. Deploy the new .wlapp file 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 MPF 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:

1. Upgrade the project using the newer version of MPF, 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. To use the new ones only, block the old ones and refer to the new ones for upgrade.

Parent topic: Deploy MobileFirst applications to test and production environments