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

 

This page answers frequently asked questions about signing native iOS, Android, and Windows Phone applications so they can be distributed to mobile device users through the EASE App Catalog. If your question is not listed here, try entering a keyword in the search box at the top right to search other pages.

 

 

What is signing?

Signing—also known as "code signing"— uses a digital certificate and private key to seal an app and identify its author. It's all about trust. Code signing assures users that the app is from a known source and has not been modified since it was last signed.

iOS, Android, and Windows Phone apps must be signed before they can be installed on a device. Because of this requirement, EASE does not let you upload an unsigned app. An app is first signed by its developer as part of the build process, therefore 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. Also, during other points in the mobile application management lifecycle, you will need to re-sign the app. For example, when you apply application policies or when an app's signing certificate expires. See this question for a list of typical reasons to re-sign an app.

EASE automates the signing process with a built-in signing server that lets you sign iOS and Android apps directly through the EASE Portal—and you do not have to be a signing expert to use it. Once signing credentials have been stored in EASE, any EASE Administrator can use them to sign apps with just one or two clicks. The signing server also provides an option for providing credentials "on the fly," in case you do not want to store credentials in EASE or in case you want to use certain credentials one time only. For instructions on using the signing server, see Sign an Application.

The signing server is not supported with Windows Phone apps. For a Windows Phone app, you can instead download a signing package to sign the app outside of EASE. You can also download a signing package for an iOS or Android app that you do not want to sign using the signing server.

 

 Click here for more information on iOS signing credentials.

To create signing credentials for iOS apps, you need to have an Apple Developer account, which you get by enrolling in an iOS Developer Program. There are different developer programs. To distribute apps to an unlimited number of users, your organization will need to enroll in the iOS Developer Enterprise Program (see this question below for more information). With an Apple Developer account, you have access to everything you need in the iOS Dev Center to create and manage certificates, identifiers, and provisioning profiles. If you do not already have an Apple Developer account, click here to enroll.

Before iOS apps can be distributed to users, they must be signed with a distribution certificate that is paired with a private key and approved by Apple. Apple acts as the CA (Certificate Authority). The distribution certificate provides the "signature"; that is, it authenticates that the app comes from an Apple-trusted source (someone who is a registered iOS Developer). A distribution certificate is not specific to a particular app; you can use the same certificate to sign all your enterprise iOS apps. An app must also be associated with a distribution provisioning profile, which authorizes devices to use the app. A distribution provisioning profile consists of a name, a distribution certificate, and an App ID. The profile should use an explicit App ID that is tied to a particular application. The profile is stored in a .mobileprovision file, which is bundled with the app when you sign the IPA file.

For details on creating signing credentials for iOS apps, see this question.

 

 Click here for more information on Android signing credentials.

An Android app must be signed with a certificate that is paired with a suitable private key. A suitable private key meets this criteria:

  • Is in your possession.
  • Represents the personal, corporate, or organizational entity to be identified with the application.
  • Has a validity period that exceeds the expected lifespan of the application or application suite. Google recommends a validity period of more than 25 years.
  • Is not the debug key generated by the Android SDK tools.

Android uses the certificate to identify the author of an app and to establish trust relationships between applications. Unlike with an iOS app, the certificate does not need to be signed by a CA. It is typical for an Android app to use a self-signed certificate. Also, there is no need for a provisioning profile or other mechanism to control who can install the app on which devices.

To sign the app through the EASE Portal, the certificate key pair must be stored in a Java keystore (JKS) and exported to a .p12 file (file in PKCS #12 format).

For details on creating the files needed to sign Android apps, see this question.

  

 Click here for more information on Windows Phone signing credentials.

A Windows Phone app must be signed with an enterprise certificate in Personal Information Exchange (.pfx) format. You need to use the same certificate to sign any native Windows Phone apps that you will distribute through EASE, including the Windows Phone App Catalog.

If you do not already have an enterprise certificate, you can acquire one from Symantec through the Windows Phone Dev Center, and then export it in PFX format using the Certificates snap-in on the computer where the certificate was imported. To do this, you need a company account on Windows Phone Dev Center. For instructions on registering on Windows Phone Dev Center and acquiring the enterprise certificate, see the Windows Phone Dev Center documentation.


What about Windows 8 Apps?

The types of Windows 8 application file formats supported with EASE do not need to be signed before they are distributed to your mobile users. For more information on the supported formats, see Windows Application File Formats.

What do I need in order to sign apps through the EASE Portal?

To sign an iOS or Android app through the EASE Portal using the signing server, you need to have the required signing credentials either stored in EASE or stored on your computer so that you can upload them during the signing process. For more information on required signing credentials, see Signing Requirements

Using Credentials Stored in EASE

To sign an iOS or Android app through the EASE Portal using the signing server, you need to have the required signing credentials either stored in EASE or stored on your computer so that you can upload them during the signing process. For more information on required signing credentials, see Signing Requirements

Using Credentials Stored on Your Computer

If you have the required signing credentials stored on your computer, you can select them during the signing process rather than use stored credentials. These can be credentials that you created, or credentials that another team member created and sent to you.

How do I create signing credentials for iOS apps?

To create signing credentials for iOS apps, the first thing you need is an Apple Developer account, which you get by enrolling in an iOS Developer Program. There are different developer programs. To distribute apps to an unlimited number of users, your organization will need to enroll in the iOS Developer Enterprise Program (see this question below for more information). With an Apple Developer account, you get an Apple ID that gives you access to everything you need in the iOS Dev Center to create and manage certificates, identifiers, and provisioning profiles. If you do not already have an Apple Developer account, click here to enroll.

Once you have an Apple Developer account, follow the steps below to create iOS signing credentials that you can store in EASE, or store on your computer for "one-time" use during the signing process. Each step includes a "Go to" link that takes you to the page in the iOS Dev Center where you can create the component; you will need to log in with your developer account Apple ID to access the page.

While your Apple Developer account may still allow you to create a wildcard App ID and then associate that wildcard App ID with a distribution provisioning profile, you should create an explicit provisioning profile for the App Catalog, each app you will distribute through the App Catalog, and any extension in those apps. Apple is deprecating support for wildcard App IDs and provisioning profiles, and may stop supporting certain functionality with apps that are signed with wildcard profiles. 

StepFor detailed instructions, see...
1

Create one Apple distribution certificate exported to a .p12 file.

Go to the iOS Dev Center: iOS Certificate (Production) page.

Distribution Certificates
2

Register App IDs.

  • Register one explicit App ID for the iOS App Catalog.
  • Register additional explicit App IDs for each of the other apps you plan to distribute through the App Catalog.  

Go to the iOS Dev Center: iOS App IDs page.

App Identifiers
3

Create distribution provisioning profiles saved as .mobileprovision files.

  • Create a distribution provisioning profile associated with the explicit App ID that you registered for the iOS App Catalog.
  • Create a separate distribution provisioning profile associated with each of the other explicit App IDs that you registered for the other apps you will distribute through the App Catalog.
Distribution Provisioning Profiles

 

How do I create signing credentials for Android apps?

Follow these steps to create Android signing credentials that you can store in EASE, or store on your computer for "one-time" use during the signing process.

StepFor detailed instructions, see...
1

Create a Java KeyStore (JKS) to store a private key paired with a digital certificate. 

Create a Keystore to Store the Private Key
2

Import the Java KeyStore to a PKCS #12 (.p12) file.

Import a Java Keystore to a PKCS #12 File

How do I create signing credentials for Windows Phone apps?

To sign a Windows Phone XAP or APPX application with the signing package, you need an enterprise certificate in Personal Information Exchange (.pfx) format. Use this same certificate to sign all native Windows Phone apps that you will distribute through EASE, including the Windows Phone App Catalog.

If you do not already have an enterprise certificate, you can acquire one from Symantec through the Windows Phone Dev Center, and then export it in PFX format using the Certificates snap-in on the computer where the certificate was imported. To do this, you need a company account on Windows Phone Dev Center. For instructions on registering on Windows Phone Dev Center and acquiring the enterprise certificate, see the Windows Phone Dev Center documentation.

How do I sign an app through the EASE Portal?

To sign an iOS or Android app through the EASE Portal, go to the Signing tab on the Details page for the app. Select the signing credentials you want to use and then click Sign. Optionally, you can choose to enable the app after it is signed and notify users of the update. For a detailed procedure, see Sign an Application. You cannot use the signing server to sign a Windows Phone app, but you can download a signing package. For more information, see Use the Signing Package.

 

To build the list of stored credentials, you or another EASE Administrator needs to add credentials to the EASE database. For instructions, see Manage Signing Credentials.

There is also an option to provide new credentials "on the fly" that are used that one time only and optionally stored for future use. To sign an app with credentials that are not stored in EASE, see Sign with New Credentials.

Can I use EASE to sign an iOS app that includes extensions and an Apple Watch (watchOS) app?

You can sign iOS apps that contain app extensions using either the EASE signing server or by downloading a signing package that includes a signing script. However, apps that contain watchOS components must be signed using the signing package and cannot be signed in EASE. For more information, see App Extensions and Entitlements.

For instructions on signing an app with the signing server, see Sign an Application. For instructions on downloading a signing package to sign an app outside of EASE, see Use the Signing Package.

Do I need to sign every app that I add to EASE?

Every iOS, Android, and Windows Phone app must be signed before it can be added to EASE. When you receive an app from a developer—whether in-house or from a third-party—the app will already be signed; signing is part of the development process. With iOS apps, the developer will have most likely signed the app with a development provisioning profile. While you can add an app that is signed with that type of profile to EASE, you will need to re-sign it with your enterprise signing credentials before you can distribute it to your users. EASE warns you when you upload an app signed with a development provisioning profile.

With Android apps, the app signed by the developer can be uploaded to EASE and distributed to users; there is no concept of a provisioning profile. You should, however, re-sign the app with your enterprise credentials after you have added it to EASE so that users are able to install updates of the app in the future. Android does not allow a user to install an update of an app if the update is signed with a different certificate than the currently installed version (see this question for more information on this scenario).

Before a Windows Phone app can be distributed to your users, it must be signed with an enterprise certificate in Personal Information Exchange (.pfx) format. It is important that you use the same certificate to sign native Windows Phone apps (in XAP or APPX formats) that you will distribute through EASE, including the Windows Phone App Catalog. 

Once apps are in EASE, there are several situations when you will want or need to re-sign the app. See this question for more information.

Do I need to sign Native App Catalogs?

iOS, Android, and Windows Phone App Catalogs need to be signed like any other native applications; Windows 8 App Catalogs do not.

If you work with Apperian to create a branded native iOS, Android, or Windows Phone App Catalog, Apperian will upload the IPA, APK, or XAP file to your EASE organization when the branding process is complete. If you choose to use the default, Apperian-branded native App Catalogs, Apperian will send you the binary files so that you can add them to EASE. After the apps are added to EASE, you can re-sign them with your enterprise credentials. For the iOS or Android catalogs, you can use the signing server or download a signing package. For the Windows Phone catalog, you can download a signing package (the signing server is not yet supported with Windows Phone apps).

The iOS App Catalog and Windows Phone App Catalog must be re-signed before they can be distributed to your users. The Android App Catalog apps are signed by Apperian with a certificate that will last 25 years (Google's recommended expiration period for Android apps); you can re-sign these apps with your organization's signing credentials, but it is not required. Note, however, that Android does not allow a user to install an update of an app if the update is signed with a different certificate than the currently installed version; if you distribute a version of the App Catalog signed with your credentials, you should sign updates of the App Catalog with those same credentials.

What is the difference between the standard iOS Developer Program and the iOS Developer Enterprise Program?

To distribute iOS apps to your employees and contractors via the App Catalog, your company needs to enroll in the iOS Developer Program. As a member of this program, you can create and use credentials that let you sign and distribute apps. For a company, there are two possible programs: the standard iOS Developer Program and the iOS Developer Enterprise Program.

  • Standard iOS Developer Program: This program is for individuals or companies who intend to develop free and fee-based iOS apps for distribution on the Apple App Store. A member of the standard iOS Developer Program can create a distribution provisioning profile (.mobileprovision file), but any app compiled with that .mobileprovision file can be distributed to a maximum of 100 specific iOS devices only. The devices must be registered through the iOS Dev Center using their Apple Unique Device Identifier (UDID) as reference. This type of distribution is call "Ad Hoc."

     How do I find a device's UDID?
    Follow these steps to find a device UDID and copy it to your clipboard:
    1. Connect the iOS device to a computer. This will launch iTunes.
    2. In the iTunes sidebar, click on the name of the device listed under Devices. This will display information about the iOS device, including its name, capacity, software version, and serial number. (If the sidebar is not displayed, click View>Show Sidebar.)
    3. Click on Serial Number to reveal the Identifier (UDID).
    4. From the Edit menu, click Copy Identifier (UDID) to copy the UDID to the clipboard. You can then paste the UDID into a file or email so that it can be used by you or your administrator when registering devices in the iOS Dev Center.

    The standard iOS Developer Program is $99 per year. Note that when you enroll as a company (versus an individual), you must provide a D-U-N-S number.
     

  • iOS Developer Enterprise Program: This program is for companies and organizations creating proprietary, in-house iOS applications for internal deployment.  A member of the iOS Developer Enterprise Program can create a .mobileprovision file to distribute an app to an infinite number of devices.

    The iOS Developer Enterprise Program is $299 per year. Note that when you enroll, you must provide a D-U-N-S number.

See Apple's documentation to read more about iOS Developer Programs. You should enroll in the iOS Developer Enterprise Program to deploy EASE without a limitation on users and devices, but you can use a standard iOS Developer Program account during test and pilot phases of your implementation when it is possible to distribute apps to a limited and specific number of devices only.

What is the difference between an Individual Developer License and an Enterprise Developer License?

An "Individual Developer License" is another way to refer to a developer's account for the standard iOS Developer Program. That is, an account that can create a distribution provisioning profile to distribute apps to up to 100 specific iOS devices. An "Enterprise Developer License" refers to an account for the iOS Developer Enterprise Program. Organizations with this account can create provisioning profiles to distribute apps to an infinite number of devices.

See this question for more information.

What is the difference between a development provisioning profile and a distribution provisioning profile?

A development provisioning profile is associated with a development certificate that identifies a single developer on a team. It authorizes an app to use certain technologies and run on designated devices during development. In order to work, it requires Xcode, which makes it useful during the app development process only. It is not for deploying apps to users.

A distribution provisioning profile is associated with a distribution certificate that identifies a team, not a team member. It authorizes an app to run on devices without the assistance of Xcode. A distribution provisioning profile is used to deploy an app to users via the App Store or other app marketplace, such as the App Catalog.

What is the difference between Ad Hoc and In House distribution?

"Ad Hoc" distribution means that the app is bundled with a distribution provisioning profile (.mobileprovision file) that identifies specific iOS devices on which the app can be installed. The UDIDs for these devices must be registered through the iOS Dev Center"In House" distribution means that the app is bundled with a distribution provisioning profile (.mobileprovision file) that does not limit distribution to specific iOS devices; the app can be installed on an infinite number of iOS devices. For your EASE implementation, you will need to use an In House distribution provisioning profile if you want to distribute apps to an an unlimited number of unspecified iOS devices. You can use an Ad Hoc profile when it is sufficient to distribute apps to a limited number of specific devices (during testing and pilot phases, for example).

 How do I find a device's UDID?
Follow these steps to find a device UDID and copy it to your clipboard:
  1. Connect the iOS device to a computer. This will launch iTunes.
  2. In the iTunes sidebar, click on the name of the device listed under Devices. This will display information about the iOS device, including its name, capacity, software version, and serial number. (If the sidebar is not displayed, click View>Show Sidebar.)
  3. Click on Serial Number to reveal the Identifier (UDID).
  4. From the Edit menu, click Copy Identifier (UDID) to copy the UDID to the clipboard. You can then paste the UDID into a file or email so that it can be used by you or your administrator when registering devices in the iOS Dev Center.

Someone with a standard iOS Developer Program account can create Ad Hoc distribution provisioning profiles only. Someone with an iOS Developer Enterprise Program account can create both Ad Hoc and In House distribution provisioning profiles.

Installing Apps Bundled with Ad Hoc Profiles

When an app is distributed "Ad Hoc," the app is listed in the App Catalog for all users with group access to the app—regardless of whether the user's device is in the list of provisioned UDIDs. If the user's device is not provisioned, however, when the user clicks the Install button, the app will download and start to install, but the operating system will terminate the installation and display an “Unable to Download Application” message. 

The operating system displays a progress indicator on the app icon (see the example to the right) until the message displays; this may take some time.

After the message displays, the icon displays in a grayed-out state. The user cannot complete the installation unless the app is updated to a version with either an Ad Hoc profile that lists the UDID for the device, or an In House profile that does not limit distribution to specific devices.

In EASE, you can use groups to organize apps so that users on non-provisioned devices do not have access to apps they cannot install. For example, if you want to distribute the HR app with an Ad Hoc distribution provisioning profile that allows the app to be installed on five specific devices only, you can add a user group called “HR Ad Hoc” that includes the users of the five provisioned devices. You can then assign the HR app to the HR Ad Hoc group so that only those five users see the app in their App Catalog. For more information on using groups, see Managing Groups.

Can I sign an iOS app with a wildcard distribution provisioning profile?

EASE does not prohibit you from signing an app with a wildcard distribution provisioning profile, but it is not recommended.

A distribution provisioning profile associates a distribution certificate with a particular App ID. An App ID can be registered for a specific application (this is called an "explicit App ID"), or it can be registered to use with any application (this is a "wildcard App ID"). When a distribution provisioning profile is associated with a wildcard App ID, it is referred to as a "wildcard distribution provisioning profile" and the .mobileprovision file can be bundled with any app.

While your Apple Developer account may still allow you to create a wildcard App ID and then associate that wildcard App ID with a distribution provisioning profile, you should create an explicit provisioning profile for the App Catalog, each app you will distribute through the App Catalog, and any extensions in those apps. Apple is deprecating support for wildcard app IDs and provisioning profiles, and may stop supporting certain functionality with apps that are signed with wildcard profiles.

What does it mean when an app "expires," and how do I fix it?

When an app "expires," it means that the credentials used to sign the app have expired. This could mean something different depending on the type of app.

With Android and Windows Phone apps, an "expired app" means that the certificate used to sign the app has expired. With Android apps, this is rare 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 currently notify an EASE Administrator when a Windows Phone app is due to expire, nor does it highlight expired apps on the Applications page. See the next section for commands that let you easily check the expiration data of a Windows Phone certificate.

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. 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. (Push notifications are not yet supported with the Windows Phone App Catalog.)

Apperian warns EASE Administrators about iOS apps due to expire in two different ways:

  • Email Notification: Apperian sends an email to the EASE administrators of your organization 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 current credentials.

    Example App Expiration Email
    Hi Example Company Administrators,
    
    You have one or more Apple signing certificates that are about to expire. Users cannot install or run apps that are signed with an expired certificate.
    
    We recommend using the Apperian Signing Server to re-sign your apps. It allows you to sign apps using a valid certificate and mobile provisioning profile without needing to keep an Xcode development environment handy. The Signing Server will also display which certificate an app was originally signed with. Access the Signing Server via the "Signing" tab on the app details page.
    Signing becomes a simple point and click exercise if you store your signing certificates with EASE (on the Settings page).
    The following iOS applications are affected:
    
    'SalesExpress (Test)' by app expires in 14 days
    
    The wiki has instructions for the Apperian Signing Server. If you require further assistance, contact helpdesk@apperian.com.
    Best Regards,
    
    EASE Account Services
  • Status Tags: On the Applications page, EASE tags expired apps and apps that are due to expire within 60 days. These tags let you track application status at a glance and stay on top of what needs your attention. 

     

How can I check the expiration date of an iOS certificate?

You can check the expiration date of an application in the Expiration Date column on the Applications page. The Expiration Date column is hidden by default; use the Show/hide columns menu to display it. In additional, status tags on the Applications page identify apps that are due to expire soon or have already expired.

You can also check the expiration date of an iOS app's signing certificate on the Signing page for the app.  

If you have an iOS Developer Program account, you can also log in to the iOS Dev Center to check expiration status, create new distribution certificates, and perform other tasks to create and manage signing credentials for iOS apps.

Apperian helps track expiration dates of signing credentials by notifying EASE Administrators about iOS 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 and provisioning profile.

You can also check the expiration date of any signing credentials you have stored in EASE. To do this, go to Signing Credentials on the Settings page.

How can I check the expiration date of a Windows Phone certificate?

If you have access to a Windows computer with the Windows Phone certificate installed, you can check the expiration date from the Internet Properties dialog. If you have the PFX file but do not have access to a computer where it is installed, you can check the expiration date at the command line.    

Check the Expiration Date from the Internet Properties Dialog

If you have access to a Windows computer with the Windows Phone certificate installed, follow these steps to check the expiration date:

  1. Open Internet Properties.

  2. Click the Content tab.

  3. Click the Certificates button to open the Certificates dialog.

  4. Look at the Expiration date listed for the certificate issued by Symantec Enterprise.
     

Check the Expiration Date from the Command Line

As an EASE Administrator, you may have access to the PFX (.pfx file) generated from your company's Windows Phone enterprise certificate, but you may not have a Windows computer with the certificate installed on it, or the credentials for logging in to the Windows Phone Dev Center to check the status of a certificate. Use one of the following commands to check the expiration date of an enterprise certificate, using the .pfx file. 

On Linux or Mac OS

 

openssl pkcs12 -in filename.pfx -passin pass:password -nokeys | openssl x509 -noout -enddate

The output will include a notAfter date indicating when the certificate expires. For example:

MAC verified OK
notAfter=Mar 20 12:22:27 2016 GMT

On Windows

 

c:\Windows\System32\certutil.exe -p password -dump filename.pfx | findstr /R /C:"NotAfter"

The output will include NotAfter dates for each certificate in the chain. The third date is listed is the expiration date for the enterprise certificate. For example:

NotAfter: 15/03/2027 0:59
NotAfter: 15/03/2032 0:59
NotAfter: 20/03/2016 13:22

When do I need to re-sign an app after it is in EASE?

After an app has been added to EASE, there are times when you will want or need to re-sign the app. Typical use cases include:

  • Sign the iOS and Windows Phone App Catalog you receive from Apperian. Before you can distribute iOS and Windows Phone App Catalogs to your users, they must be signed with your organization's credentials. Android App Catalogs are signed by Apperian with a certificate that will last 25 years (Google's recommended expiration period for Android apps); you can re-sign the Android App Catalogs with your organization's credentials, but it is not required. The Windows 8 App Catalog is signed by Apperian and does not need to be re-signed before you distribute it to your users.
     
  • Sign an iOS or Windows Phone app that has a certificate that is due to expire soon or has already expired.  When the distribution certificate used to sign an iOS or Windows Phone app is due to expire or has already expired, you need to re-sign the app with a valid certificate and redistribute the newly signed version to your users. See this question for more information.
     
  • Sign an app that was signed with third-party or development 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). Your in-house developers will most likely sign an iOS app with a development certificate rather than a distribution certificate. In both of these cases, you should use the signing server to re-sign the app with your enterprise signing credentials. With Android apps, a user will not be able to install an update of an app if the update is signed with a different certificate than the currently installed version; therefore, you should re-sign Android apps with your enterprise credentials before you make them available to your users.
     
  • Sign an app after wrapping it with application policies. You can wrap an iOS or Android app to apply security and usage policies. Depending on the policies applied, the app may need to be updated and re-signed. If it does, EASE displays a "Pending Signing" status on the Policies page and flags the app on the Applications page. You need to re-sign the new, wrapped version of the app before you can make it available to users. (Application policies are not yet supported with Windows Phone apps, so you will not need to re-sign them for this reason.)

    If you use the signing package to sign an app that is wrapped with policies, and then upload that newly signed version to EASE, you should not re-apply policies to that app. If you do, the app will no longer function properly. If you need to modify an app's policies or apply new policies, you need to first upload the original version of the app.

  • Sign an app that was created by adding a hybrid app to EASE. A 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 so it is signed with the same certificate as the Windows Phone App Catalog. All native Windows Phone applications you distribute through the App Catalog must be signed with the same enterprise certificate used to sign the App Catalog. When you upload a Windows App app (XAP or APPX), you will need to re-sign it if it is not already signed with the same certificate as the App Catalog.

Do I need to re-sign an app with the same credentials it was signed with previously?

With iOS and Android apps that have been installed on any of your users' devices, it is important that you re-sign the apps with the same credentials they were signed with previously. If you sign an app with different credentials, users will not be able to install an update of the app.

With Windows Phone apps, you need to be sure to sign the app with the same enterprise certificate used to sign the 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.