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. Because of this requirement, EASE does not let 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 in EASE. 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 EASE

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

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 EASE. 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 a certificate that is about to expire

All certificates must be renewed periodically. Before a certificate expires, apps that were signed with that certificate 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 one year. When an app's certificate expires, the app will fail to run on the device. EASE does not notify an EASE 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 certificate or the distribution provisioning profile used to sign the app has expired. If the app includes extensions and is therefore signed with multiple provisioning profiles, EASE bases the expiration date on the date of the certificate or provisioning profile due to expire the soonest. 
    • Apple distribution certificates expire after one to two years, and distribution provisioning profiles expire after one year. 
    • When an iOS app is signed with an expired certificate or profile, users cannot install the app from an App Catalog or run the app if it was already installed. Therefore, it is important to re-sign apps with valid credentials and redistribute the newly signed versions before they expire. 
    • You can use status tags and the Expiration Date column on the Applications page in EASE to stay on top of what needs your attention. You can also view the expiration date on the Signing page for the app or under Signing Credentials on the Settings page.  

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 EASE. 

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

hybrid app is a type of app that you can add to EASE 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, EASE 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.

Re-sign an App

You will occasionally need to re-sign an app that was already signed. Some common scenarios include:

  • An app is expired or due to expire.
  • An app was signed with third-party or development credentials.
  • After you apply policies to an app.

You should re-sign an app before the certificate expires so there is no disruption of service to your users. Apps with an expired distribution certificate are highlighted on the Applications page. Apperian notifies EASE administrators about apps due to expire. Notification emails are sent 60 days before an app expires, 45 days before, 30 days before, and then every day until the app either expires or is re-signed with a current distribution certificate.

Best Practice

When you re-sign an iOS app through EASE, you can select the "Notify users about the update" option to send a Push Notification to the devices of all users who have already installed the app.

If you are signing an app that was previously distributed to any users, you can mark the update as mandatory to ensure users install the new app file created when you sign it. For more information, see Managing Application Updates.

Note

When you re-sign an app that was already installed on any of your users' devices, it is important that you sign it with the same signing credentials used to previously sign it.

  • iOS and Android do not allow a user to install an update of an app if the update is signed with credentials that differ from the currently installed version.
  • Windows Phone apps must be signed with the same enterprise certificate used to sign the Windows Phone App Catalog. Therefore, if you upload a new version of the app, you need to sign it with the same credentials as the previous version, unless the App Catalog has been re-signed with a different certificate, in which case you would need to re-sign the app with that certificate. 

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 EASE:

  • Name, version, App ID, and platform of the application
  • EASE 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