Sign on the digital line

How iOS developers use code signing to get their apps on iPhones

Developing apps is actually the easy part. Things get difficult when it comes to getting apps onto devices. One of the biggest hurdles iOS developers face as they take their apps to market is not learning the basics of the iOS Human Interface Guidelines, or following the posted guidelines for getting through Apple’s App Store review process. Rather it is the difficult and often times frustrating process of code signing the app for distribution.

One of the benefits that curators like Apple and Google can gain from code signing apps is that it provides a means of stopping malware from spreading, especially when the platform only allows code signed apps to be installed. Just this past week Google took measures to suspend a particularly malicious group of apps labeled as malware from being distributed in Google Play. With 99 percent of all mobile malware targeting the Android platform, preventing such threats from spreading is something that any app store operator like Google would want to ensure its customers it has the situation under control.

The question, however, is how effective are the various platforms at enforcing such actions for all of its users. The answer to this question lies in how these very same users choose to allow such threats from affecting their devices. While code signing of apps is a tool that developers and app store operators can use, it is not always effective.

Code Signing Apps

Code signing is not new, it has been around since before mobile apps were as prevalent as they are today. Simply put, Code Signing is a means of identifying where a particular piece of software originated. Developers use a unique digital key to sign their software, and then register that key with a trusted digital signing authority. That trusted digital signing authority can then validate the key and certify that the software did in fact come from a particular developer.

Windows – On Windows, when you first go to launch an application for the first time you may have seen error messages like “The Publisher could not be verified. Are you sure you want to run this software?.” What this means is that either there is no code signing key associated with the software you are trying to use, or that no digital signing authority could verify which developer it came from. The problem is that most will ignore the message and continue to launch the app anyway. Some have even modified their Security Settings to allow the launching of applications and unsafe files without being prompted by this message.

OS X – When Apple fist launched the Mac App Store for apps on their OS X platform, a new default option was introduced in the System Preferences. Under Security and Privacy, users quickly learned that three Gatekeeper options now existed when it comes to determining what apps could be launched on a Mac. Only apps downloaded from the Mac App Store, apps from identified developers, or apps from anywhere. Just like on Windows, OS X users are empowered to choose which apps they want to run on their Macs and even disable all warning messages when installing any app from anywhere.

Android – With Android, the option to install apps from unknown sources in not only an option that users can configure in their security settings, they are encouraged to do so by operators of Android App Stores outside of Google Play. The instructions on Amazon’s own Android App Store label the instruction as “Allow installation of apps from the Amazon Appstore.” Sounds friendly enough, however users are instructed to allow apps to be installed from unknown sources; any unknown source, not just Amazon. While it is true that Android developers can sign apps before deploying them to device, they don’t really have to. There are plenty of ways that developers can deploy apps to Android devices that do not require any level of code signing at all. Side-loading apps by tethering the device with a USB cable, downloads apps from web sites or even install apps from an attachment in an email message are some examples.  While Google may have some control over Google Play, it does not control the Android platform as a whole.

iOS – The exception to this behavior lies in ensuring that the rule is always applied; by not giving users the option to turn it off. Apple, the trusted digital signing authority for iOS, has taken on the additional role of governing which developers are permitted to deploy apps onto iOS devices. On iOS there is no option to install native apps from any other source than Apple’s own iOS App Store (or an approved Enterprise App Store as outlined below). Without jailbreaking an iPhone, even developers cannot deploy apps that they are developing onto iPhones without Apple knowing about it.

So how exactly do apps get onto iOS devices?

Xcode is an app available for free on the OS X app store and can also be downloaded from the Apple Developer website. This is the tool that developers use to create apps. Without paying $99 for an Apple Developer Account, deploying code to devices simply will not work. Developers are limited to deploying and testing in a iPhone Simulator that runs on their Mac. Only after enrolling in an Apple Developer Program can developers deploy apps to a device:

Ad-hoc – One way this is done is by registering up to one-hundred iOS devices with their Apple Developer Account. This requires developers to manage all one-hundred of the device’s UDIDs, or unique device identifiers. Once registered to their account, developers can then tether each device to their Mac and deploy the app directly from within Xcode. The one-hundred device limit is a hard limit, you cannot remove and add devices at will. Once a year you can clear all registered devices from your list of registered devices and start over again.

TestFlight – Apple recently announced that it will shut down TestFlight’s ability to deliver apps to registered devices via email, which is a move that will send many developers over to alternatives like HockeyApp. In its place Apple is now promoting a new TestFlight Beta Testing capability. Managed directly from within a tool know as iTunes Connect, this now allows developers to send out early releases of their apps to as many a one-thousand devices without having to manage each device’s UUID. Not only does this increase in beta testers help developers manager their testing cycles better, it also makes managing the beta testing phase much easier.

App Store – The goal of most developers is getting their app into the App Store. This requires one to work through the intricacies of creating an AppID, TeamID, Distribution Certificate, and Provisioning Profile from within an Apple Developer account. Once this is completed, developers soon realize that the battle is only half over, as they then need to create an iTunes Connect account and register for an available App Record which is necessary to upload and submit your app for review. It never goes quite as planned the first time around and you end up spending a fair amount of time troubleshooting what step you missed. When all is said and done, you realize that you could actually make a career out of helping developers shepherd their apps through this process.

Enterprise – There are times when you want to develop apps that you never intend on deploying to the App Store, such as apps that you consider part of the intellectual property of your company and intend for use by employees of your company only. Even when this is the case, Apple still governs what apps can and cannot be deployed to some degree by continuing to manage the code signing process. This requires enrollment in Apple’s Enterprise Development program for $299 a year. Developers go through the same amount of hassle code signing their apps. This prevents third-party entities from creating their own public App Store for distributing apps. Companies can however deploy apps they develop exclusively to other business.

Known as B2B distribution, this is only possible if the company that the app is being deployed to has an internal means of managing app distribution. They must have their own Enterprise App Store.  When this is the case, enterprise deployment is the way that apps get code distributed to devices under the management of an MDM solution like MobileIronApperian or AirWatch.

5 Responses to “How iOS developers use code signing to get their apps on iPhones”

  1. Mio Nilsson

    “Developing apps is actually the easy part. Things get difficult when it comes to getting apps onto devices.” – couldn’t be further from the truth. Code signing is the easiest part, even in the iPhone OS 2.0 days when code signing was difficult compared to now it was still the easiest part.

    What’s difficult is building the right thing and building hat the right way.

    • Patty_Manager

      You have obviously never written any iPhone apps. The “code signing” process is (at least) a 14 step VERY unclear process.

      It could (and should be) 2 steps:
      1. Enter info on this 1 line.
      2. Click this button.

      It’s not. Apple has made it extremely UNFRIENDLY. There are countless non-Apple
      documents that try desperately to better explain the process.

      Our company switched from iOS apps… to Android apps… just because it is SO much
      quicker and easier to get things done.

  2. Aaron Freimark

    This is a great summary of a ridiculous complex system. But unfortunately it is even a bit more complex that this. There are two methods available for enterprise distribution, not one, but they are conflated above.

    Enterprise distribution is targeted to in-house development teams, and is available to members of the Enterprise Developers Program, $299 per month. This allows companies to sign their home-grown apps (using Xcode) and distribute them internally. This process does not use iTunes Connect, and Apple does not review the apps for private frameworks, etc., as they do for app store apps. The terms and conditions of this program limit distribution to employees ONLY. Apps can be distributed using a private App Store hosted on MDM, or installed with just a simple web page.

    B2B distribution is a different program, targeted to contractors, available with the $99 standard developer program. iTunes Connect is used here, and Apple does review each app. It is very much like the public App Store, except a developer can limit distribution to one or more enterprise customers. Developers can even charge different pricing (or no price!) for different customers. Customers must enroll in the iTunes VPP program to receive the apps, then deploy the apps through MDM.

    I hope that is helpful.