Impact of migrating to a new version of MobileFirst Studio for applications already in production

Since IBM Worklight Foundation v6.2.0, there is a separation between the MobileFirst Server runtime environment and the MobileFirst apps or adapters.

This separation generally means the following:

• When you deploy a runtime environment that was built using MobileFirst Studio v6.2.0 into MobileFirst Server v6.2.0.1 or later, we can deploy applications and adapters of any version, from V5.0.6.

• If we do not increase the application version when you rebuild it in the new MobileFirst Studio, important features such as app authenticity will fail for the old clients and they will not be able to connect to the MobileFirst Server.

For Direct Update and app authenticity to work, both the client application and the server-side artifacts (wlapp) must be generated from the same version of MobileFirst Studio.

In certain cases, if you migrate the project.to a new version of MobileFirst Studio, and even if you do not change the code of the application, you must still increment the version number of the application. If we deploy a new, upgraded runtime environment (meaning one that was built with the new MobileFirst Studio), it is possible to deploy both versions of applications - the one built with an older version of MobileFirst Studio and the one that was upgraded and built with a new version of MobileFirst Studio, with a different application version. We can still serve the older, existing client application along with new ones, or block the old ones and refer to download of the new ones.

There are three such cases:

• Applications created with a version of Worklight Studio older than V5.0.0.3. The communication protocol of Worklight Server v6.1.0 supports the protocols of client applications that are built with IBM Worklight V5.0.0.3 or later. Device users who use apps that were built with IBM Worklight V5.0.0.3 or later, and whose server-side artifacts have been successfully deployed to IBM Worklight v6.1.0 and tested on a test server should continue to work without requiring the device user to download a new version of the application.

  Device users who use applications that were built with IBM Worklight V5.0.0.3 or later, whose server-side artifacts were regenerated using the newer version of Worklight Studio, and that are successfully deployed to Worklight Server v6.1.0 and tested on a test server should continue to work without requiring the device user to download a new version of the application. However, Direct Update and app authenticity are not available for these applications.

• Applications that use the Direct Update feature. The Direct Update feature (Direct updates of app versions to mobile devices) to automatically update application versions stops working after some migration paths. Worklight Studio v6.1.0 displays a warning when such situations are detected when migrating apps created in older versions.

  To notify the users that a new version of the application is available, we can use the startup display notification feature that is documented at Displaying a notification message on application startup. If the application update is mandatory, another alternative is to deny access to the old application version using the feature that is documented at Remotely disabling application connectivity.

  If you need to upload a new version of the application to a public application store such as the Apple Store or Google Play, you must in some cases resubmit the app for approval by the store.

• Applications that use application authenticity. App authenticity will not work properly for clients built with an older version of MobileFirst Studio when the app that is deployed on the server was built with a newer version of MobileFirst Studio, and both have the same application version. Requests from those clients to access resources that are authenticity-protected will always be denied.

Parent topic: Upgrading to MobileFirst Studio v6.3.0