iOS App Signing

Introduction

The iOS App Signing feature can be used to “(re-)sign” existing native iOS apps (*.ipa archives) with new signing credentials while changing bundle properties conveniently from Relution. During the process, the existing code signature and properties of the app are replaced and the (re-)signed app version is uploaded back to Relution automatically.

You can configure apps so that they are automatically signed. If enabled, each new version of the app is signed automatically using a configuration defined in the Relution organization settings.

Some possible usage scenarios are:

  • Renewing an expired provisioning profile without having to build the app again

  • Signing an app created by a supplier with the organization’s own signing credentials

  • Replacing the development signature with the production signature during release of a new app version

The signing feature cannot be used for public apps added from the Apple AppStore.

Prerequisites

For the app signing feature to be available for an app version, some prerequisites have to be fulfilled:

  1. The signing feature has to be configured system-wide by the system administrator.

  2. Signing is only available for *native iOS apps*

  3. The user has to have Developer, Reviewer or Owner permissions on the app to be signed.

If all conditions are met, the Re-sign action will be available on the app version’s details page and auto-signing can be configured on the app details page or during app creation.

A valid combination of signing credentials and properties is needed to (re-)sign an iOS app. The signing credentials can be provided as an Apple Enterprise Developer account in the Relution organization settings or provided ad-hoc as a valid combination of signing identity certificate and provisioning profile.

Signing Credentials

Automatic Signing

The necessary credentials for app signing can be set in the Relution Settings at Settings > App Signing. The following parameters will be necessary:

  • Platform type: Apple to add a configuration for signing iOS native apps

  • Bundle ID Pattern: This pattern defines which apps the configuration is used for. Apps which have the given bundle identifier or match the identifier using a wildcard (*) at the end will be signed. Each instance of the automatic signing configuration needs to have a unique Bundle ID pattern. When multiple patterns match an app’s bundle identifier, the most specific one, ie. the one with the longest non-wildcard pattern, will take precedence.

  • Apple ID: The Apple ID associated with an Apple Enterprise Developer account

  • Password: The password for the Apple ID. If the ID is protected with two-factor authentication, an app specific password has to be created.

  • Signing Certificate: The distribution signing certificate associated with the developer account as a PCKS 12 archive. This has to be provided as it contains the signing private key which cannot be obtained by Relution via the Apple Developer Portal.

If an automatic signing configuration is used for signing, Relution will do the following things in the given Apple Enterprise Developer Account during the signing process:

  1. Create App Identifiers necessary for signing apps if they are not present already

  2. Create Provisioning Profiles every time an app is signed to have the maximum time until expiration

  3. Create Push Certificates if possible

Automatic signing cannot be used with standard Apple Developer accounts

Ad-hoc

The credentials can also be provided ad-hoc during signing. The following data has to be provided:

  • Signing Identity Certificate A PCKS 12 archive containing the development team’s signing identity certificate and private key

  • Signing Identity Certificate Passphrase The passphrase to decrypt the archive

  • Provisioning Profile An iOS provisioning profile (*.mobileprovision) matching the signing identity

When credentials are provided ad-hoc, Relution is not able to create app identifiers, provisioning profiles or push certificates.

Signing-Operations

Signing uploaded apps

When automatic app signing is enabled, each added version of any app is automatically signed when an app signing configuration with a matching Bundle ID pattern exists. The signed app is uploaded to Relution and then available as a separate app as it has a different bundle identifier

The setting can be enabled when creating a new app or on the app’s details page.

Manually signing apps via Relution Portal

  1. Navigate to the app to be signed

    image

  2. Choose the app version to be signed and click on Re-sign

    image

  3. Select the signing credentials to be used. The switch controls if the automatic signing settings from the organization settings should be used or if the credentials are provided ad-hoc. If properties of the app should be changed expand the section CHANGE PROPERTIES at the bottom and enter new values for the bundle properties which should be changed. Finally confirm by pressign Re-Sign.

    image

  4. The app version will then be resigned in the background and an e-mail notification will be sent when the signing process has finished.

    image

  5. The new app version is available in Relution. (Depends on the selection of properties, see section Consequences of signing an app version)

    image

  6. The existing app version will be available under Archive unless a certain combination of properties are set. (See section Consequences of signing an app version)

    image

Changing app Properties

The following properties can be changed when signing an iOS App manually

  • Bundle Id (CFBundleIdentifier): The bundle id which the signed app should be set to – has to match the App ID of the provisioning profile

  • Display Name (CFBundleDisplayName): The bundle display name which will be shown for the resigned app

  • Short Version (CFBundleShortVersionString): The desired bundle release version of the resigned app

  • Build Version (CFBundleVersion): The desired bundle build version of the resigned app

Push certificates

When an app is signed with Automatic Signing Credentials (upon upload of a new app version), or when triggered manually, a new push configuration is created if there is still room for one and one doesn’t already exist. A PEM file containing the configuration is delivered to Relution together with the signed app, and can be downloaded from the app detail page after the signing has finished.

Consequences of signing an app version

Depending on the combination of signing identity and properties the following cases are possible:

  1. Replacing the version which will be signed

  2. Adding a new version to the same app

  3. Creating a new app

  4. Adding a new version to a different, existing app

  5. Replacing a version of a different, existing app

Replacing the version which will be signed

This will happen when the bundle identifier and bundle build version are not changed or set identical to the properties of the app version to be resigned. This happens because Relution identifies app versions uniquely by the combination of those two properties. This will lead to the app version to be signed being replaced by the newly signed version.

The existing app version will be deleted

Some example uses are changing an app’s display name or replacing an app’s provisioning profile

The user needs to have sufficient permissions for the app to delete the existing version and to create new versions

Adding a new version to the same app

This will happen when the bundle identifier is not changed or set identical to the app version to be signed but the bundle build version is changed. A new, additional version will be added to the same app and the version to be signed will still be present (but could be moved to the archive, see Release status handling).

Some example uses are renewing an app’s expired provisioning profile or changing an app’s shown version.

The user needs to have sufficient permissions on the app to be signed to create new versions

Creating a new app

This will happen when the bundle identifier is changed and no app with this bundle identifier is already present in the organization in Relution. This will lead to a new app being created in Relution. The existing app to be signed will remain unchanged.

Some example uses are signing an app created by a supplier with the organization’s own signing credentials for the first time or replacing the development signature with the production signature during the first release of a new app.

The user needs to have sufficient permissions to create new apps

Adding a new version to a different, existing app

This will happen when the bundle identifier is changed and an app with this bundle identifier is already present in the organization in Relution but no version with the same bundle build version as the signed app will have. A new, additional version will be added to existing app. The app to be signed will remain unchanged.

Some example uses are signing a new app version created by a supplier with the organization’s own signing credentials or replacing the development signature with the production signature during the an update release of an app version.

The user needs to have sufficient permissions on the existing app to create new versions

Replacing a version of a different, existing app

This will happen when the bundle identifier is changed and an app with this bundle identifier is already present in the organization in Relution and it already has a version with the same bundle build version as the signed app will have. The existing version of this app will be replaced. The app to be signed will remain unchanged.

An example use is renewing an expired provisioning profile of an app from a supplier.

The user needs to have sufficient permissions on the existing app to delete the existing version and to create new versions

Release status handling

In which release state the new app version is put depends on both the release status of the app version to be signed and the user’s permissions.

  1. The app version to be signed is in Release or Review The new app version will be put into Review if the user has sufficient permissions or else in Development

  2. The app version to be signed is in Development or Archive The new app version will be put into Development if the user has sufficient permissions or else in Review