“Porting desktop apps to cloud service is a breeze!” — said no one ever

One of the challenges we faced when we started developing this service was how to get a secure and scalable implementation to wrap iOS apps. iOS apps have some unique properties when compared to Android applications. First of all, iOS applications require MacOS to develop the apps. Wrapping iOS apps follows a similar process as developing iOS app and therefore requires many tools available only on MacOS. Our initial idea for this problem was, “sure, we’ll host MacOS servers on cloud.” And, reality started to kick in.

We implemented proofs of concept using MacOS cloud services, but we realized fairly quickly that these services were mostly IaaS, rather than PaaS. A few more iterations of proofs of concept and we realized that we needed a better solution.

What does it take to move our code from MacOS to something else? Here are some of the issues we encountered:

  • lipo
  • otool
  • plutil
  • codesign

These tools are important tools for developing iOS apps. If you are iOS app developers but have not heard of these tools, that’s because Xcode does a great job hiding these tools from you. These tools become even more important when wrapping an iOS apps.

Lipo has a very interesting name. It sounds like liposuction, doesn’t it? It is a tool to extract, list, and do other things to Mach-O binaries from Fat binaries.  Fat binaries, sometime called universal binaries, contains multiple Mach-O binaries in them. We need this tool to inspect, add, and remove Mach-O binaries; if necessary.

Otool is another important tool. We need them to inspect the app to find out what kind of binary it is. Is it Fat binary or plain Mach-O? What kind of processor does the binary support? Arm? Arm64? Is it built for Apple App Store?

Plutil is a tool to let us manipulate property lists that Apple uses extensively on iOS and MacOS. iOS app developers are familiar with Info.plist where the application metadata is stored. That file actually can store key-value pairs in various formats: binary, XML, and JSON.

Last (but not least), there is codesign. This tool is probably the most important of all. Codesign tool cryptographically signs the app to prove that it is developed by authorized Apple developer. Without this tool, you cannot install and run the app on iOS device.

So, how did we solve these problems?

We wrote them from scratch. However, we are not completely feature parity with these tools, as expected. For example, we can’t sign an app that has never been signed before. We also cannot sign an app that does not have enough space to store the newly signed structure. Adobe AIR iOS app is an example of this. It is signed with a relatively old structure and does not leave any space to store an updated signature structure. Unfortunately, at this moment, we need to fail the wrap process for these apps.

Security

When we started working on this project, security was the biggest concern and it is still our biggest concern. Since we need to handle Apple’s signing certificate and private keys, we must ensure utmost caution on how we handle these customer assets. In our current implementation, we are not storing signing certificates, passwords, private keys, alias key name (Android), alias password (Android), and iOS mobile provisioning profile. We ensure this by temporarily passing customer private assets to Azure Key Vault via Citrix Cloud and deleting them immediately after the wrap operation. We also ensure each wrap operation is a reset to a clean slate by using a combination of VMs and container technologies.

We get few requests to support wrap apps in batches. We are calling these requests as “batch wrapping.”  To support batch wrapping with best admin experience, we would like to store the signing certificates, passwords, and provisioning profiles.  That will let the admins wrap the app without uploading the certificates, password and provisioning profile every time.   We think our current handling of customer assets will hold up against security concerns, but we need to work even closer with our security team to ensure this.

Please stay tuned!

EMM banner