Why Mobile App Code Signing is Challenging for DevOps Teams

App signing is no longer just for developers

Mobile app signing, the process of digitally signing mobile app executables, is a requirement for  installation. Anytime an app is changed it must be re-signed.

App signing has typically been the responsibility of the developers who built the mobile app. However due to increased demand for mobile apps, which can come from many sources (such as  internal development teams or third-party ISVs) AND the need to perform post-development app modifications, that responsibility is changing. DevOps and IT Ops are increasingly tasked with deploying mobile apps sourced from many places and must perform various application deployment activities to get mobile apps to end-users.

Complicated and cumbersome

Also referred to as ‘code signing’, the mobile app signing process is not just a formality; it is a required step to allow most apps to be installed on mobile devices.

Historically, app developers and publishers signed mobile apps to protect apps from being tampered with or altered, and to establish differentiation from pirated apps. Signing has evolved to confirm the app author's identity and guarantees the code has not been changed or modified. App stores will reject any app that is unsigned. Additionally, if the user attempts to install an app by some other means such as sideloading, the package installer will reject the installation.

App developers understand the development lifecycle and release process that includes app signing. Yet, as much as they do, developers still struggle to get this right, and release mismanagement is a common occurrence.

Now, let’s add DevOps and IT Ops to the mix. These teams are not intimate with the app development lifecycle and release process. They are infrequently involved with these activities. Since they don’t perform these functions often, these teams need to relearn the processes continually. Often, ‘documentation’ is nonexistent or outdated, and the procedures are complex and mundane.

Moreover, the iOS and Android app signing procedures are very different. Let’s get into those details.

iOS app signing is exceptionally intricate and rigid

While Apple has a well-documented process for iOS App Signing, this is the OS platform for which the most signing issues are encountered. Apple encourages signers to use and follow the Xcode signing process. Xcode is Apple's integrated development environment (IDE) for building apps targeted at Apple devices.

A unique and essential element to iOS app signing is “Provisioning Profiles.” These profiles contain app information and entitlements, which specify the system resources an app can use. A provisioning profile acts as a link between the app testing device(s), the developer account, the app, and the app container in the Apple App Store. The same provisioning profile must be used for both the initial signing and any re-signing. 

Apple enforces code signing and they control the process. Moreover, Apple is the only code signing authority for iOS apps. While developers, DevOps, and IT Ops sometimes view this as inflexible or inconvenient, it is advantageous for users and the entire ecosystem. This rigidity means users can have high confidence that iOS apps are safe and malware free, as they are vetted, reliable, and secure. Given the importance mobile apps play in both the enterprise and consumer markets today, security is of utmost importance, and Apple’s approach reinforces this point.

Android signing is more flexible and less secure 

On the other hand, Android developers have the option to sign apps before deploying them to a device. But this is not a requirement: developers can also choose to not sign an app. It reflects Google’s Android open design philosophy of “to make sure that there would always be an open platform available for carriers, OEMs, and developers to use to make their innovative ideas a reality.” While Google has some control over Google Play, it does not control the Android platform as a whole.

There are several ways developers can deploy apps to Android devices that do not require any code signing. Apps can be ‘side-loaded’ by physically connecting the device with a USB cable.

It is important to note that one of the biggest complaints about Android is how easy it is for a third-party, side-loaded app to cause problems on an end user's mobile device. Issues include the risk of creating app and OS instability and enabling malware to install itself.

Why apps sometimes need to be re-signed

Apps often need to be modified after the development process is ‘complete.’ There are many reasons why this happens, including changes required to the underlying infrastructure, security controls, performance management, or analytics functionality overlooked during the initial code build. Or the organization may have acquired the app from a third-party vendor that doesn’t provide the needed functionality, for example, app-level security controls that work with the organization’s UEM solution. Or, because DevOps/IT Ops needs to deploy an app to different places, a private app catalog instead of a public app store. Whatever the reason, once an app is modified, it needs to be re-signed. Sending it back to developers will cause uncontrollable delays, especially if it has to be re-signed by a third-party vendor.

App signing checklist for DevOps/IT Ops

With all this in mind, here are the key activities that DevOps and IT Ops team should pay attention to when approaching the app signing process:

1. Use the correct certificates. DevOps/IT Ops need to obtain the proper distribution certificates, typically from the development team. If DevOps/IT Ops cannot do the signing, they need to engage the signing team for re-signing. Within a large organization, there is typically a separate team for this function.
   
   
2. Review provisioning profiles and entitlements. This can be particularly challenging with third-party apps, as DevOps/IT Ops has to coordinate with the third party to get the provisioning profile and make sure the profile's entitlements are correct.
   
   
3. Re-sign apps when needed. An app may need to be re-deployed, and therefore re-signed, multiple times a year by DevOps/IT Ops for reasons previously discussed. If anything has changed, such as a new app version that needs updating with a different provisioning profile, DevOps/IT Ops will run into issues. This is especially common when apps come from third parties.

Challenges with scaling your app portfolio

If your mobile app portfolio grows to ten, twenty, or more apps, each of which comes from a different vendor, things get really complicated and challenging. 

But it doesn’t have to be this way. When code signing is performed as part of a workflow via a platform that orchestrates the various deployment activities, the platform can ensure rigor over the entire process. Other functions can remain manual if complete automation isn’t an option, for example, when a separate signing team is required because the organization wants to restrict who has access to the certifications. In such a situation, a notification system can ensure that the required team is notified when an app is ready to be signed. Mixing manual and automated steps also retains rigor over the deployment process as the deployment workflow will only move ahead once someone from the signing team has provided a signed version of the app.

Orchestration can provide time and resource savings because it can easily scale signing, no matter your mobile app portfolio's size. And signing can be part of the natural orchestration workflow.

Blue Cedar orchestrates, simplifies the app signing (and re-signing) process

The Blue Cedar Platform is purpose-built for deploying mobile apps and eases the pain of app deployment through a unique set of services and orchestration of deployment activities. App signing is one of the supported activity types, which means that DevOps and IT Ops no longer have to worry about the reliability of executing a necessary activity that they may perform somewhat infrequently.  

Platform users define mobile app deployment workflows that help coordinate internal teams, enhance apps with new security features, and integrate with popular app deployment services.  Codifying the variety of actions that are needed to ensure successful signing of a mobile app into a “signing step” vastly simplifies the app signing process and ensures reliable repeatability. For example,  the Platform ensures the use of the correct provisioning profile for iOS apps. Using the right provisioning profile is mandatory to prevent certain features from breaking, like push notifications (that rely on the bundle ID or package name), apps that require shared keychains or app groups (dictated by the provisioning profile), or license keys for third party software tied to the specific bundle ID or package name. The Platform also integrates with existing mobile security and deployment tools, making it easy to use existing technologies’ functionality to perform deployment activity types in workflows. It  also makes it easy to demonstrate compliance with security policies and regulations by tracking all deployment activity and providing reporting data. Learn more by reading the Blue Cedar Platform white paper.