About the Citrix MDX Toolkit
Mobile app management allows you to securely manage and deliver mobile apps to users. With the Citrix MDX Toolkit, you can wrap iOS and Android apps to secure access and enforce policies. The MDX Toolkit inserts logic and policies into each mobile app.
The tool can securely wrap an app that was created within your organization or a mobile app made outside the company. When you install the MDX Toolkit, the Worx SDK libraries also install and appear in the MDX SDK folders on your computer in the tool and data directories. The MDX SDK folders are required for the integration of wrapped iOS mobile apps with Citrix Worx. When you wrap iOS apps that include the Worx SDK libraries, you can publish the apps in the Apple App Store and the Citrix Worx Store.
After you wrap the app, you can upload the app to XenMobile App Edition (App Controller) and configure MDX policies. When you upload a mobile app to XenMobile App Edition, the app is validated during installation. You can upload mobile apps that have the extension .mdx.
The MDX Toolkit runs on a computer running Mac OS X Version 10.7 (Lion) and above. The tool is not supported on a Windows-based computer.
The MDX Toolkit for iOS and Android Apps is available for download in the Worx Mobile Apps section found at the following location:
For iOS apps wrapping, you need the following basic pre-requisites:
- An iOS mobile app .ipa file
- The iOS Distribution Provisioning Profile
- Distribution Certificate to sign the apps
For Android apps, you need the following basic pre-requisites:
- An Android mobile app APK file
- Java Development Kit (JDK) 1.7 on your computer
- Android Software Development Kit (SDK) on your computer. https://developer.android.com/sdk/index.html#download
- A keystore for signing Android mobile apps
Note: To wrap apps for Android Version 4.3, you need to install the JDK 1.7
Link to download JDK 1.7.
For More information on deploy MDX Tool Kit please refer to the below link:
Ad-Hoc or AppStore app
There could be some issues wrapping a native mobile app. Before we start to wrap the app we should know if the application is for Ad-Hoc distribution or meant for AppStore distribution. We know that an app meant for AppStore distribution does not work when wrapped.
The big question is how to identify whether an application is developed for Ad-Hoc distribution or for public.
One way to find out if an .ipa file is for AD-Hoc or App Store is to look inside the embedded.mobileprovision file.
How to view the embedded.mobileprovision file
- Convert your .ipa file into .zip by simply replacing the extension to .zip.
- Extract the zip file.
- Do show package content
We need to communicate to the customer the checkpoints, which can help us know application is meant for what kind of distribution.
- Open Terminal and ‘cd’ to the folder containing your copy of the embedded.mobileprovision.
Ex. /downloads/payload/demo.app mymac$
- Run: security cms -D -i embedded.mobileprovision
The difference between ‘Ad-Hoc’ and ‘App Store’ require some additional checks. The ‘get-task-allow’ key will be set to false for both of these kinds of distributions:
However, ‘Ad-Hoc’ builds have a defined set of ‘ProvisionedDevices’ which is not present in ‘AppStore’ builds:
<string>abcdef01234567890abcdef01234567890abacde</string> <string>1abcdef01234567890abcdef01234567890abacd</string> <string>2abcdef01234567890abcdef01234567890abacd</string> </array>
Enterprise or AppStore app
How to check if IPA was configured to Apple store deployment
1) Rename IPA file to ZIP and unzip
2) Right click on file contained within and click on “Show Package Contents”
3) Find main binary name, it should have the same name as the package, and no extension. Copy it to somewhere else.
4) Run the following command
> otool –l AppBinary | grep crypt
5) If there is a “cryptid” field displayed and its value contains non-zero, the binary has DRM applied. This means it was configured for apple store deployment
bash-3.2# otool -l <appBinary>|grep crypt
Here the crypt id is “0” which means this app is not for AppStore.
Few cases where the wrapped app does not works
Fail to wrap apps which does not contains icon in info.plist file.
Some of the native applications, which fail to wrap, and logs at the time of wrapping did show “icon mandatory” error message.
Further investigation disclosed that the applications that didn’t have .png icon files in info.plist would fail to wrap, as icons are mandatory.
Wrapper logs with error
2013-11-10 14:38:12 [ManifestLib] Could not find Icon entry in /var/folders/fd/ysj_md4d4hb84cqs46gvkf1c0000gn/T/C7049A2B-25A1-4B02-984C-8C10238D224D-11445-000113EE58EC99C2/Payload/globedemo-ipad.app/Info.plist , icons are mandatory
2013-11-10 14:38:12 [ManifestLib] Error:- We are not able to add MobileApp section into manifest XML file
2013-11-10 14:38:12 [PrepareTool Wizard] Failed to generate this file: manifest.xml
Application wrapped with warning message:
In few cases we have found that application is converted into MDX format while wrapping but does displays a warning raising suspicion whether it will work or not.
If you’re doing an Ad Hoc distribution, you must properly configure your project to include an Entitlements.plist file and uncheck the get-task-allow checkbox (which sets it to False). The get-task-allow entitlement allows an app to be debugged on a device.
As of Xcode 4.2 the get-task-allow entitlement is automatically set to true or false, depending on what kind of provisioning profile you sign your application with (Developer, Ad Hoc, or App Store).
Bad binary file
There are cases where the wrapper is not an issue but the actual binary provided is not valid.
To make sure that you have a valid binary, upload the unwrapped ipa/apk file directly on to the device, if the file gets uploaded the file is good else need to fix the ipa file.
Failed to execute dylibcodesign with exit code: 1
“Failed to execute dylibcodesign with exit code: 1
2013-10-16 16:44:17.132 CGAppCLPrepTool[14605:707] [CommandLine] Failed to execute dylibcodesign with exit code: 1″
Note: Dylib error in the logs suggests that the issue is with the wrapper.
If the logs while wrapping contains the above error there could be various reasons for that:
1. No command line tool installed in XCode
While wrapping the app you get above error message. This could be if you don’t have the command line tool in XCode. Use this link for more details. http://support.citrix.com/article/CTX135253
2. Expired or invalid Provisioning cert
This could be a signing problem.There could be a possibility that your Provisioning cert has expired or you have both the expired as well the valid cert in the Keychain.
Go to Applications->Utilities->Keychain Access on your Mac and check for the validity of the provisioning cert. Expired cert normally has an onerous red ‘X’ circle.
3. Reinstall XCode
Other thing you can try is to remove XCode completely. Then do a complete new installation of XCode with command line tools.
Note: If you are running Apple Xcode 4.5 or later versions, you also need to install the Xcode command-line tools from the Xcode Apple Developer web site.
Use the below URL to download latest Xcode https://developer.apple.com/xcode/
4. Certificate trust policy not set to Default.
The blue circled plus sign next to the distribution cert (and developer cert) indicate the certificate trust policy settings are not using the Default System cert trust policy setting, but is using an Always Trust policy setting which the user had explicitly set on the certificate.
The current certificate trust facility does not appear to always trust certificates, which are explicitly trusted in this manner.
Double click to Open that certificate and change its trust policy setting back to use System Default, terminate keychain app, logout, and reboot.
Make sure you go to https://www.apple.com/certificateauthority to install the latest Apple Root Certificate Authority certs. And intermediate authority certs. Etc.
5. Private key not imported in the KeyChain.
Along with the Provisioning Profile we also need to make sure that we have the Private key imported in the keychain. After the import Provisioning Profile should like as displayed in the screen shot.
[PrepareTool Wizard] ERROR: Could not sign the application.
Logs while wrapping:
You need to use a DSA key:
You must sign your applications with a key that meets the following guidelines:
- 1024 bit keysize
- DSA key algorithm (keyalg)
- SHA1with DSA signing algorithm (sigalg)
Application uses “Ajax” for communication with Web Server. When they changed configuration from Sync to Async for MDX wrapped application, it worked generally. If there is any mobile application which uses Ajax Sync to communicate with the web sever and is wrapped with the Citrix MDX Tool Kit, normally it fails. Application side if you change the communication from Ajax Sync to Ajax Async then it works.
The fix for this will be available in the Nike MDX Tool Kit.
Clip Framework native app failed after wrapping
We found out that one of our customer’s native mobile application which is based on “Clip” framework was not able be controlled with any MDX policy after wrapping.
What clip is?
It is a hybrid web application development framework which supports various smart phone OS platforms. CLIP based application is generated in standard WEB technology.
Do we have any limitation to support applications?
Regarding cross compiler based apps, like Clip framework apps, it is very likely that they don’t work well with MDX as is. We need to see how they generate the mobile apps (source code) to understand their app framework. Usually, this type to cross-compiled apps do not follow standard program flow as native programs, on which MDX
There will be app compatibility issues with MDX in general.
WorxHome compatibility with wrapper.
XCode compatibility with wrapper
There could be a possibility that the XCode version on the MAC system is not compatible with the Citrix MDX Tool Kit and the wrapped app might not work as expected always refer to the Citrix download section for the latest information.
XenMobile8.6 download section link.