Applies to Pega Platform versions 7.1.1 through 7.4

Symptom

Attempts to upload a Pega Mobile app for iOS trigger ITMS errors. The Apple App Store rejected the submission. Some of the errors are straightforward: For example, the version number must be set to 1.2 because 1.1.1 is the current version of the Pega Mobile app on the App Store. Other errors indicate that a few icons are missing. Errors related to the framework signing might be contained to the Pega Platform™.

Errors

The errors reported here are caused by mistakes in settings and resources uploaded to mobile app views, which prevent the iOS app from passing Apple validation.

The errors indicate two issues:

• Enterprise security policy interferes with the re-signing of the framework certificates.
• Icon problems are caused by incorrect assets branding.

Root Cause Analysis

The mobile app did not have the required assets.zip, bundle ID, and version number for valid submission to the Apple iTunes store.

The Build Server, when building a mobile app, makes sure that the app installs and starts on mobile devices. It also does its best to check if everything Pega provides (code, not customizable resources) will not prevent the app from passing app store validation. Unfortunately, the Build Server, does not validate resources and settings provided by the app developer because it does not know whether the app is going to be submitted to app stores.

The following ideas are under consideration for product enhancements:

• Add a check box to the mobile app view for the developer to indicate that the app will be submitted to app stores.
• Add a checklist that helps the developer ensure that each release build of an app is ready for submission.
• Add a feature that fails the build if the developer has not met the minimum requirements.

Root Cause and Solution #1

Enterprise security policy interferes with framework certificates re-signing

Hybrid Container 7 uses modules based on frameworks; Hybrid Container 6 does not. Each framework must be signed with a certificate.

Once the developer uploads the certificate and the mobile provisioning profile file (named default.mobileprovision) to the Dev Studio, both are sent to the Build Server during the build and used to sign all the frameworks and the final IPA file.

The security policy of the enterprise reporting the issues prevented uploading the production App Store certificate to the Dev Studio. To work around this problem, the developer attempted to re-sign the IPA file locally. Unfortunately, this did not work because of the fact that each single framework would have to be re-signed as well. As a result, during the IPA submission process, there was a burst of signing issues.

Prior to Pega 7.2.2, the work-around to bypass the security policy worked because the previous version of the app used a different architecture.

Solution #1

The solution to re-sign the IPA along with the framework would require the Pega team to deliver and use the xcarchive file for the enterprise reporting this problem.

The Pega team used HC Distribution Package, HC Proprietary information hidden version, and built the Client locally.

See the PDN resources in Related Content.

Root Cause and Solution #2

Icon problems caused by incorrect assets branding

Icon problems were observed in both the Pega 7 Build Server and the local Build Server because of wrong assets branding.

The default assets branding have a common_assets folder with a SVG icon in size 2048x2048. It is used by Build Server to create all necessary icon sizes automatically.

For the case reported, the developers uploaded the assets branding ZIP file without the common_assets folder and with the iOS folder and the Android folder only. As a result, the Build Server was not able to generate all of the required icons. This caused a problem during IPA submission.

The same set of icons were also with the local Build Server, but this failed as well.

Solution #2

The Pega team provided the enterprise with a customized customization.zip with the common_assets folder and instructions on how to fully customize it.

With a clean HC Proprietary information hidden distribution package and customization.zip prepared properly, the local Build Server run with the ant pega command generated all the required icons and filled the PLIST file properly.

Choose one of the following approaches:

• Use the Pega 7 Build Server with the final AppStore Certificate along with the correctly created branding assets.
• Use the local Build Server with the correctly created customization.zip file.

This second approach was the better choice for the enterprise who reported the case described in this article.

Both approaches are supported and described in the PDN Articles listed in Related Content.

Best Practices

To prevent ITMS Errors with your Apple App Store submission, consider the following recommendations:

• ​Allow more than two weeks for an Apple App Store submission. One to two months is recommended.
• After the mobile app binary is approved, hold the binary in Pending Developer Release status indefinitely.
• After the server URL and log-in credentials are available, submit the mobile app binary to the Apple App Store: There is no reason to wait.
• Build your binary using the Pega Mobile Build Server with a distribution certificate.
• Ensure that all frameworks (libraries) are dynamically linked because the latest Pega Mobile app binaries are built using the latest Swift technology, which requires dynamically linked libraries.

• This is the Apple recommended way and the only way for Swift-based iOS binaries.
• This requires that all frameworks and the Swift folder inside the IPA be re-signed.

• When updating an existing application, always use the latest assets.zip file and follow the latest set of instructions.

Instructions are likely to change outside of Pega Platform release cycles because they are controlled by Apple and Google.

Related Content

Building a mobile app locally

Developing custom Pega Mobile Client modules for iOS in Pega 7.2.2