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 and Android 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.


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 App Management. 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 App Management 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 an 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 App Management. 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 Customer Support

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

Best Practice

We recommend re-signing iOS and Android App Catalogs. The Windows 10 App Catalog is signed by Customer Support 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 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. 
  • 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 App Management. 

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 App Management 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. 

Back to Top

View Signing Activity

You can use the Feeds API to view a history of signing activity. For more information, see Feeds API. The feed includes the following information about applications that were signed using App Management:

  • 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

Report Columns

With iOS apps, the Cert Name field lists the name of the distribution certificate used when signing the app. With Android apps, the Cert Name field 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