This is part two of a two-part article. You can find the first part here.
In the first half of this article, we answered the question of how companies are able to build and distribute in-house apps when all iOS apps have to be signed by Apple. The answer, of course, lies in the iOS Developer Enterprise program, which we examined previous. For the second half this article, we’re going to look at managing in-house iOS apps.
There are essentially three ways to manage these apps (though we’ll see that one of these three methods doesn't really count). The techniques are: through the certificate used to sign the app, building management into the app itself, and through MDM configuration profiles. (If you’re not familiar with the basics of MDM and MAM, check out this article from Brian.)
Assuming no other form of management is present, the only way to control an enterprise-signed app is to revoke the distribution certificate. This can be done by both the app creator or by Apple; the result is when the app checks in with Apple (which is every few days), it will learn that it doesn’t have permission to run anymore. Of course this “management” option is very rough, because all the copies of the app out there authenticate to the same certificate, so if you revoke it, you kill all of them at once!
Another issue is that these certificates are only valid for a year. To use an app for longer, you have to recompile it with a new certificate and have all your users update to the new version. But wait! The certificates and provisioning profiles described in part 1 of this article don’t include any way to force an app to update. What is the company to do?
Enter mobile application management (MAM)
The company that created the app for its employees could always just tell everybody to update the app automatically, but for a much better solution, the app can have built-in functionality that forces users to update. Keeping up to date is just one of many management tasks a company would want to do with an app; the other important tasks are things like setting password protection, app-level VPNs, encryption, and being able to remotely revoke access.
All of these management tasks have to be built into the app itself. While each individual app could be developed with its own management system, it makes much more sense for all the apps a company deploys to be controlled by a single management platform. One way of doing this is to use a software developer kit that contains a library of code that can hook the app into a pre-built system—this way there’s no need to reinvent the wheel for each app your company develops.
Another option for building these management features into apps what’s known as app wrapping. Instead of building the features into the app from the beginning, the app wrapping process takes an existing compiled app, inspects the code, adds additional code for all the management features, then compiles the code into a new app. This is great for when a company wants to distribute an app that somebody else built. (App wrapping can also be used to block certain app behaviors by intercepting API calls. Neat, right?)
Finally, a different type of app management comes from controlling who has access to the app in the first place. This means putting the provisioning profiles on secure web pages or using a corporate app store product. While these techniques get labeled as MAM, you can see that this type of management, while important, is not really in the same league as app-wrapping and SDKs. Or in other words, when somebody’s selling you MAM, make sure you know whether you’re just getting an app store or if you’re getting more advanced features. (For more on this, check out Is an app store really mobile application management?)
Notice that the one thing we can’t do using these app management techniques is completely uninstall an app from a device. (Though it is possible to make an app so that it just won’t run. This often gets described as remote wiping, but the term kill pill would be a better descriptor.)
In order to remove an app from a device, the company must be managing the device using an MDM configuration profile, and the provisioning profile that installed the app in the first place must have been delivered through that MDM configuration profile. To remove the app, an administrator simply changes the configuration profile so that it no longer includes the provisioning profile of the app in question. Bingo—no more app! Now that we're talking about both MDM and MAM, though, some other interesting issues come up:
For this discussion so far, I've been referring to the technical capabilities of mobile device management configuration profiles, not MDM companies themselves. While many MDM vendors solutions also include MAM components, it's good to know that the MDM config profiles are exactly the same for every vendor. (What are the capabilities of these profiles? The iPhone Configuration Utility is a good way to get familiar. Some vendors’ solutions do differ a little bit by including agent applications that can collect even more information about a device, such as location or jailbreak detection.)
Using only MAM tools and not MDM config profiles, it is possible to make apps that are secure and manageable on unmanaged devices. But since a configuration profile provides a lot more information along with extra management options, some MAM solutions also install an MDM configuration profile to take advantage of these options. After all, why not take advantage of all possible sources of information? Well, for one thing, there are privacy issues when it comes to having config profiles on employees personal devices, since config profiles can tell administrators what other apps are installed on the device...even though many consumers willingly download apps that report all sorts of information to random untrusted sources...but this is an issue for another article.
With the knowledge that MDM solutions also do MAM and that many MAM solutions use MDM configuration profiles, the MDM versus MAM debate becomes less relevant. The industry seems to be coming to a consensus that using MDM config profiles as a part of a MAM solution is still considered MAM and not MDM (the product). Whatever your opinion on device versus application management is, knowing what MDM configuration profiles can and can’t do—as well as knowing what application-level management can and can’t accomplish—is essential for evaluating any enterprise mobility management product, and for distributing in-house iOS applications. (My first reaction when hearing about any mobile management product is always to ask whether or not it uses configuration profiles.)
Once in-house apps are created and signed using the iOS Developer Enterprise Program, MDM configuration profiles and various MAM techniques allow those apps to be managed in different ways. Choosing which methods to use depends on device ownership and a many other variables, but this article should have provided some basic background for the process.
There is one last question, though, and it’s a huge one: What about Android? Why aren’t we talking about it right now?
The short answer is because it’s so much more complicated. The long answer would require several articles (or an entire book). With Android, we have to deal with 3 (or now 4-ish) major versions of the OS floating around, multiple ways to sign apps or make devices run unsigned apps, plus a variety of 3rd party vendors that all have their own sets of custom APIs for managing apps and devices—the whole scene is just not as well-defined. Some of the MDM and MAM issues covered here, though, apply equally to deploying Android apps.