Building an application for a test or production environment

To build an application for a test or production environment, you must configure it for its target server. To build an application for a production environment, additional steps apply.

1. Make sure that the target server keystore is configured.

   For more information, see Configuring the MobileFirst Server keystore.

2. If you plan to distribute the app installable artifact, increment the app version.
3. Before you build your app, configure it for the target server.

   You define the URL and runtime name of the target server in the client properties file. You can also change the target server by using the IBM MobileFirst™ Platform Command Line Interface (CLI). To configure the app for a target server without registering the app to a running server, you can use the mfpdev app config server <server URL> and mfpdev app config runtime <runtime_name> commands. Alternatively, you can register the app to a running server by running the mfpdev app register command. Use the public URL of the server. This URL is used by the mobile app to connect to MobileFirst Server.

   
   For example, to configure the app for a target server mfp.mycompany.com with a runtime that has the default name mfp, run
   mfpdev app config server https://mfp.mycompany.com
   and
   mfpdev app config runtime mfp.
4. Configure the secret keys and authorized servers for your application.
   1. If your app implements certificate pinning, use the certificate of your target server.

      For more information about certificate pinning, see Certificate pinning.

   2. If your iOS app uses App Transport Security (ATS), configure ATS for your target server.
   3. To configure secure Direct Update for an Apache Cordova application, see Implementing secure Direct Update on the client side.
   4. If you develop your app with Apache Cordova, configure the Cordova Content Security Policy (CSP).
5. If you plan to use Direct Update for an application that is developed with Apache Cordova, archive the versions of the Cordova plug-ins you used to build the app.

   Direct Update cannot be used to update native code. If you changed a native library or one of the build tools in a Cordova project and uploaded such a file to MobileFirst Server, the server detects the difference and does not send any updates for the client application. The changes in the native library might include a different Cordova version, a newer Cordova iOS plug-in, or even an mfpdev plug-in fix pack that is newer than the one that was used to build the original application.

6. Configure the app for production use.
   1. Consider disabling printing to the device log.
   2. If you plan to use IBM MobileFirst Analytics, verify that your app sends collected data to the MobileFirst Server. For more information, see Sending analytics.
   3. Consider disabling features of your app that call the setServerURL API, unless you plan to make a single build for multiple test servers.
7. If you build for a production server and plan to distribute the installable artifact, archive the app source code to be able to run non regression-tests for this app on a test server.

   For example, if you later update an adapter, you might run non-regression tests on already distributed apps that use this adapter. For more information, see Deploying or updating an adapter to a production environment.

8. Optional: Create the application-authenticity file for your application.
   You use the application-authenticity file after you register the application to the server to enable the application-authenticity security check.

   • For more information, see Enabling the application-authenticity security check.
   • For more information about configuring application authenticity, see Configuring the application-authenticity security check.
   • For more information about registering an application to a production server, see Registering an application to a production environment.