+

Search Tips | Advanced Search

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


Build an application for a test or production environment

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


Procedure

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

    For more information, see Configure the MobileFirst Server keystore.

  2. If we 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. We 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, we can use the mfpdev app config server <server URL> and mfpdev app config runtime <runtime_name> commands. Alternatively, we 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 our 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 our 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 we plan to use Direct Update for an application that is developed with Apache Cordova, archive the versions of the Cordova plug-ins we 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 we 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 Deploy or update an adapter to a production environment.

  8. Optional: Create the application-authenticity file for our application.

    We use the application-authenticity file after you register the application to the server to enable the application-authenticity security check.


What to do next

Register and configure the application in the production server. For more information, see Register an application to a production environment.

Parent topic: Deploy MobileFirst applications to test and production environments