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 MobileIron, Apperian or AirWatch.