Page tree
Skip to end of metadata
Go to start of metadata


Signing (also known as code signing) uses a digital certificate and private key to seal an app and identify its author. This process identifies an app as belonging to your organization and ensures that the app has not been modified since it was last signed. 

iOS, Android, and Windows Phone native apps (including native App Catalogs) must be signed before they can be installed on a device. The Admin Portal will warn you if you upload an unsigned app. Windows 10 apps do not need to be signed before they are distributed to your mobile users. 

An app is first signed by its developer as part of the build process, so when you receive an app—whether from an in-house or third-party developer—it will already be signed. Depending on the type of app and the signing credentials (the certificate and other components needed for signing) used by the developer, you may need to re-sign the app before you can distribute it to your users. For more information, see Use Cases.

Prerequisites

Before you can sign an app, you must have the appropriate signing credentials (the certificate and other components needed for signing). You won't create signing credentials through Apperian. Someone at your organization must create the appropriate signing credentials (each platform has its own requirements) before you can actually sign an app. To learn how, see Signing Prerequisites.

Methods

Apperian provides two methods for signing apps. Which method you use depends on the app's platform and how it was created.

Sign with the Admin Portal

Administrators can use the Admin Portal to sign native iOS and Android apps before distributing them to users. For more information, see Sign an App (Portal).

Signing Package

To sign a Windows Phone app or iOS app with watchOS components, you can download a signing package that includes the app's binary file and a script for signing the app on your computer. You can also download a signing package for signing an iOS or Android app if you prefer to sign the app outside of Apperian. For more information, see Sign an App (Signing Package).

Back to Top

Use Cases

The following scenarios are typical reasons why you would need to sign or re-sign an app.

Sign the App Catalog that you receive from Apperian

After branding your App Catalog, Apperian uploads it to your EASE organization. You can then sign the App Catalog app with your organization's credentials.

Best Practice

Apperian recommends re-signing iOS, Android, and Windows Phone App Catalogs. The Windows 10 App Catalog is signed by Apperian and does not need to be re-signed before you distribute it to your users. 

Sign an app with credentials that are about to expire

All signing credentials must be renewed periodically. Before credentials expire, apps that were signed with those credentials must be re-signed with a valid certificate. Users cannot install expired apps from an App Catalog, and cannot run an expired app that was already installed.

  • With Android and Windows Phone apps, an "expired app" means that the certificate used to sign the app has expired. 
    • This is rare for Android apps since the the certificate's private key typically has a validity period of 25 years or more to ensure that an app can be used and updated for the lifespan of the app. Therefore, you will not typically need to re-sign an Android app because it has expired. 
    • Windows Phone enterprise certificates typically expire after 1 year. When an app's certificate expires, the app will fail to run on the device. Apperian does not notify an administrator when a Windows Phone app is due to expire, nor does it highlight expired apps on the Applications page.
  • With iOS apps, an "expired app" means that either the distribution certificate or the distribution provisioning profile used to sign the app has expired. For more information, see iOS App Expiration

Sign an app that was signed with a third-party's credentials

If a third-party builds an app for you, they will sign it with their own credentials (unless you provide them with your credentials). This use case can include your internal developers who sign apps with their unique developer credentials. You should then sign the app with your organization's credentials.

Sign an app after applying application policies

You can apply security and usage policies to iOS and Android apps. Apps with policies must be signed before you can enable them in Apperian. 

Sign an iOS or Android app that was created by adding a hybrid app

hybrid app is a type of app that you can add to Apperian if you want to deliver a web app to your users as part of a native iOS or Android application. When you add a hybrid app, the Admin Portal creates a new native app that must be signed before it can be enabled and distributed to your users. 

Sign a Windows Phone app with the same certificate as the Windows Phone App Catalog

All native Windows Phone apps must be signed with the same enterprise certificate used to sign the Windows Phone App Catalog. When you upload a Windows Phone app (XAP or APPX), you must to re-sign it if it is not already signed with the same certificate as the App Catalog.

Back to Top

List Signing Activity Report

You can run a Signing Activity report to list the following information about applications that were signed using Apperian:

  • Name, version, App ID, and platform of the application
  • User who performed the signing
  • Date and time of signing
  • Name of the provisioning profile used for signing
  • Name and description of the certificate used for signing

For instructions on using the report, see Run a Report.

Report Columns

With iOS apps, the Cert Name column lists the name of the distribution certificate used when signing the app. With Android apps, the Cert Name column lists the CN (Common Name) specified when the private key was generated. The App ID, Provisioning Profile, and Creds Description columns are hidden by default.

Back to Top