This is the first part of a two-part article. You can find the second part here.
When dealing with mobile apps and mobile app management, one question that comes up occasionally is how companies distribute home-grown iOS apps without using the Apple App Store. It’s a logical question, since every iPhone user knows that apps have to be signed and approved by Apple. The answer lies in the iOS Developer Enterprise Program, which we’ll look at in the first part of this article. In part two I’ll cover related issues: the differences between distributing enterprise apps with and without MDM configuration profiles, and where MAM providers step in.
Distributing in-house apps
We know that for publicly available iOS apps the Apple App store approves (or rejects) apps that are submitted by developers, signs the code, and then distributes them. This is good enough for probably 99% of the apps—even business related ones—that users will want. (For me, most of the apps I use for work are simply clients for SaaS offerings that my company uses. For example, we use Concur for expenses, and I found the publicly-available app on my own. No need for my employer to worry about distribution.)
Naturally, there will be some apps that a company will want to build itself and distribute only to its own employees, and for that Apple provides the iOS Developer Enterprise Program. To enroll, a company must have provide a DUNS number, and the cost is $299 per year.
So how do apps get from developers’ laptops to employees’ devices?
Even though these apps are private, Apple is still involved in this process. They won’t be inspecting each individual app, but the apps will still have to check in with Apple to make sure that they’re allowed to run. Deploying an app under the iOS Developer Enterprise Program works something like this: (This is a rough overview of how the process works, but you’ll get the idea.) A company has a brand new internal app they just developed, so they request a distribution certificate by submitting a certificate signing request (CSR) to the iOS Provisioning Portal. This is an automated process that takes just a few seconds, and even though Apple is giving out the certificate, they still don’t know anything about the app other than its name. The developer then uses Xcode (an iOS developemnt tool) and the certificate to sign the app. Xcode is also used to create a provisioning profile, which is an xml file (using the extention .plist) file that contains a link to the actual application binary (.ipa file) and a few other details about the app.
To install an app on users’ devices, the provisioning profile can be distributed in several ways; for a company with more than just a few users it would likely be by using an MDM configuration profile to deliver the provisioning profile or simply having users download the provisioning profile via a text message, email, intranet site, or corporate app store product (found in many MDM and MAM offerings). Once the provisioning profile is installed, it in turn downloads and installs the actual application binary, which was signed in the process described previously. When the app loads, it checks with Apple to make sure the certificate used to sign it is valid. Sounds simple, right?
Unfortunately, a few caveats:
I’m going to cover application management issues in part 2 of this article on Friday, but for now, let’s look at some the issues with the iOS Developer Enterprise Program itself.
First, while Apple isn’t inspecting your apps, your apps still need to have their permission to run. That means that Apple can take away permission for enterprise apps to run at any time. Good thing Apple is so transparent and enterprise focused—um...yikes! Imagine all the terrible things that could happen: suddenly the mobile clients for your critical line of business apps are all gone! It’s enough to make anyone swear off iOS and run to HTML5 apps. Seriously, though, this has never actually happened (though it has happened for public Apple App Store apps).
There are other sticky issues, as well. Apps signed by an enterprise certificate are for distribution to employees and contractors, but it’s pretty murky just how loose that definition can become. Unlike provisioning profiles signed using the regular iOS developer program (the $99 program that 20 year olds use to create the next billion-dollar start-up apps), which must name the specific devices the apps will run on, provisioning profiles signed with enterprise distribution certificates can install apps on any iOS device. The potential for trouble here is obvious. If you want to distribute your apps to other customers, the solution is to give them the binary, and have them provide their own enterprise certificate.
I should also mention that there are a few other ways of distributing custom or in-house apps, but these don’t come up as often in the mobile app management landscape right now: Apps can be installed directly onto devices without using a provisioning profile (as long as the apps are signed) using the iPhone Configuration utility or iTunes; or provisioning profiles can be installed using the iPhone Configuration Utility. Since these methods require devices to be connected via USB, they’re not really considered viable in corporate situations. There’s also the Apple B2B program, which involves submitting apps the normal Apple App Store review process, but making them available only for specified customers to buy using the Volume Purchase Program (VPP). (There will be a little more about the VPP in part 2.)
We see that even in-house apps are to some degree at the mercy of Apple’s will, but by developing and distributing with common sense, it shouldn’t be too much of an issue. In the second half of this article (which will be published on Friday), we’ll look at the manageability of corporate iOS apps, with or without MDM configuration profiles.
(Please continue on to Let’s take a look at in-house iOS apps, part 2 of 2: Managing the apps)
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.