Re-signing for the Branded Mobile App Publisher

Discover how to re-sign your branded mobile app

Last Updated

October 2nd, 2020

Reading Time

6 min

User Level


In your learning platform, you can create a branded mobile app for your users’ on-the-go learning. In this way, your learners can do their training on a mobile app branded for your company.

Refer to this article to learn how to create and configure your branded app, generate the build and then download the package in order to publish your custom version of the Go.Learn mobile app on the app stores. To know technical requirements and information needed to create your own branded app, refer to this article.

If you publish your app on iOS App Store, you are required to submit the Export Compliance and the Self-Classification Report for Encryption Items in order to be compliant with the U.S. Encryption and Export Administration Regulations (EAR). To know how to produce and present this report, refer to this article.

This article outlines how to re-sign your branded mobile app. Once you’ve created your branded app, in order to publish it on the application store (Google Play for Android and App Store for iOS) you have to replace the digital signature temporarily applied by Docebo with your own signature generated in-house (for Android) or with the signing certificate assigned by the App Store (for iOS).

If you don’t apply the new signature, the package can’t be uploaded on the application store. Refer to the following sections for more information about the re-signing process for Android and for iOS.

Please note that Branded Mobile App Publisher is a very technical functionality. We suggest contacting a member of your company’s IT department to perform the configuration properly.

Also note that Docebo is not responsible for the content of external documents written by other companies (i.e. Apple, etc.). Remember that it is your responsibility to check if these documents are updated or changed in any way.

Android Google Play Store

The re-signing process for the Android Google Play Store is composed of two steps. You must first create a keystore if you don’t have one yet. If you already published an Android app, you can use the same keystore. Then, you need to re-sign the Android Package (APK) or the Android App Bundle (AAB), according to the package format you chose when configuring the app technical details in the Settings section of the Android app tab.

Creating a Keystore

Begin by creating a keystore using the Java Keytool utility that comes with any standard JDK distribution and can be located at %JAVA_HOME%\bin. On Windows, this is usually C:\Program Files\Java\jre8\bin., while you don’t need to care about the path on Mac OS.

On Windows, open a command prompt and switch to that directory. On a Mac, just open a terminal. Then, enter a command like this one:

keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

The Keytool prompts you to provide passwords for the keystore, then you will be asked to provide the Distinguished Name fields:

creating a keystore android re-signing

Finally, type the password for your key (if required). The keystore is now generated as a file called my-release-key.keystore saved in the directory in which you’re currently located. The keystore and the key are protected by the passwords that you entered. The keystore contains a single key, which is valid for 10,000 days (as given in the -validity parameter) .The alias is the name that you will use later to refer to this keystore when signing your application.

Please note: Save the keystore and the password for later uses, because you’ll have to use them anytime you need to publish an update.

To learn more about Keytool, you can refer to this Oracle document. You can also find a detailed document about this topic on Stack Overflow.

Re-signing the .apk or the .aab

In order to reassign a signature to an APK or to an AAB, you have to delete the META-INF from your APK or your AAB and use jarsigner to sign it again. Remember that you shouldn’t extract the files; you just need to remove the entry from the archive. You can do it in many ways, but the fastest way is using the system shell.

Let’s assume that you have a MyApp.apk file (or a MyApp.aab file) and a keystore called ‘my-release-key.keystore’, the alias is ‘alias_name‘, the keystore’s password is ’secret’ and the key’s password is ‘password123‘. If you don’t have a keystore, refer to the Creating a Keystore section above for further information on how to create it. Follow these steps to re-sign the .apk or the .aab file:

1. Remove the META-INF directory from the archive:

zip -d MyApp.apk META-INF/\* or zip -d MyApp.aab META-INF/\*

2. Sign it again:

jarsigner -keystore ./my-release-key.keystore your-app.apk alias_name or jarsigner -keystore ./my-release-key.keystore your-app.aab alias_name

3. Realign the app in order to be compliant with the Play Store tech requirements. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file (please note: follow this step for .apk files only)

zipalign -f -v 4 your-app.apk your-app-aligned.apk

There is no security risk from the shell history because the passwords for your keystore and key are asked on the console. You are now ready to upload this .apk (or .aab) to the Android Google Play Store. Read this article to learn more about how to reassign a signature to an Android .apk file.

As an alternative way to perform this re-signing process, you can use two tools created by Google, zipalign and apksigner. For further information about these tools, refer to this article.

Please note: when using tools like zipalign and apksigner, the operating system you are using may affect the command syntax that is used. The zipalign command above would require the full path to where the tool is located within OSX. For example:

/Users/{YOUR_USER_NAME}/Library/Android/sdk/build-tools/{SDK_VER}/zipalign -f -v 4 ./your-app.apk your-app-aligned.apk 


Refer to this Google article for more information about how to upload an app.

Apple App Store


In order to perform the re-signing process for the Apple App Store, you need:

Apple prerequisites Re-signing

Re-signing the .ipa

In order to re-sign the iOS .ipa package, a series of tools that are only available on Mac OS X are necessary, therefore you can’t re-sign an iOS app using a Windows PC. An .ipa is a zip file. In order to modify it, you have to extract it, sign it again and re-compress it. Follow these steps to re-sign the .ipa file:

1. Move MyApp.ipa to a folder of your choice

2. Download the new Provisioning profile embedded.mobileprovision from the Apple Developer Console and save it into the .ipa folder (see point above)

3. The running security find-identity will give you a list of identities, from which you can choose the one you want (you have to search for the one starting with “iPhone Distribution”):

security find-identity -v -p codesigning

The result will be like the following:

  1. 7D2A35B002F0577B66689713044BF66B4EEAC70F “iPhone Developer: Donald Duck (4J2CJZQ799)

  2. C45CFD22CCC7BD2E84ED43D07719D709BC901322 “iPhone Distribution: A.C.M.E. (8YX56B3FLL)

4. Move the script to the same folder and run it (run the script without args to have more info):

$   MyApp.ipa embedded.mobileprovision   “iPhone Distribution: A.C.M.E. (8YX56B3FLL)”

This .ipa is now signed with your new profile and you are now ready to upload this .ipa to Apple App Store using the application called Transporter (you can find it in your Application folder). If you don’t have Transporter yet, you can install it from your Mac App Store.

Refer to these articles (How to re-sign iOS builds, Inside Code Signing and Application Code Signing) to learn more about how to reassign a signature to an Apple .ipa file.


You also need the following metadata to finish setting up the app in iTunesConnect:

App Specific Info

Apple app specific info Re-signingVersion Specific Info

Apple version specific info Re-signingRefer to the following articles for more details about screenshot requirements and optional preview requirements, and read this article for further information.

Please note: when uploading your branded app on Apple App Store, if you use custom SSO (Single Sign On), Apple may require an explanation about the reason why you use a non-standard login process.