Over the last couple of weeks we’ve seen that iOS 7 is going to bring some significant enhancements for the enterprise. However, there are still plenty of areas where Apple could give the enterprise mobility management industry some more guidance. One of these is around how apps that work with mobile app management are distributed.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
We’ve talked a lot about the different ways to acquire MAM-compatible apps, but the problem is that some of the schemes for distributing them do not fit easily into the techniques provided by Apple. There’s a well-defined distribution model for apps that just have one version that everyone buys from the Apple App Store, as well as for apps that are proprietary in-house apps intended for just one company. The problem is that many MAM apps fall into a gray area in between these two use cases.
Official Apple-sanctioned techniques
First, to set a baseline, let’s recall the standard techniques Apple has for distributing apps:
- Normal mass distribution through the Apple App store: This is what any regular app developer does to sell his or her app, and indeed probably the way the majority of us get most of our work apps, too: The developer builds an app, submits it to Apple for approval, and then anybody who wants to can buy it. Simple and straightforward.
- Enterprise-signed apps: Companies that need a proprietary app can develop it in-house, or hire contractors to develop it. Then using the iOS Developer Enterprise Program, the company signs it and then is allowed to distribute it to their own employees (but not anybody outside the company.) Apple does not inspect these apps.
- Custom B2B apps: An alternative route for custom apps, except in this case apps are distributed and signed using the Apple App Store mechanism, and the iOS Developer Enterprise Program is not required. B2B apps must be approved by Apple, but like enterprise-signed apps they are only available to the employees of the specific company for which they were developed.
Outside the official techniques
Some of the app distribution techniques that are used in the mobile app management industry don’t easily fit in with these Apple-sanctioned techniques. To make things worse, Apple doesn’t provide very much guidance on these cases, either. Much of the information for this article came from countless conversations I’ve had over the last year or two with MAM vendors, ISVs, and IT pros, not official Apple documentation.
Anyway, there are two main distribution issues that come up with MAM-compatible apps:
- Some ISVs have multiple, similar versions of their apps in the public Apple App Store.
- Some MAM apps are distributed without the Apple App Store, and instead the apps are signed through the iOS Developer Enterprise Program.
Let’s look at both of these in depth.
Multiple, similar versions of apps in the store
Why does this happen? Since there are several MAM vendors with competing ecosystems of apps and MAM protocols, ISVs that want their apps to be compatible with more than just one MAM vendor often produce multiple versions of their apps. The result is that you might go to the Apple App Store and find “App X,” “App X, MAM vendor Y edition”, and “App X, MAM vendor Z edition.”
But apparently Apple doesn’t like having duplicate versions of an apps in the store, and all indications are that modifying an app to work with a MAM protocol doesn’t change it enough for Apple to consider it a new, unique app. The B2B program doesn’t really provide an alternative, either, because B2B apps are intended to be used by just one company.
Bypassing Apple controls
There are several ways that ISVs and MAM vendors distribute MAM-compatible apps that completely bypass the Apple App Store, but they all share the same basic concept: the iOS Developer Enterprise Program is used to sign and distribute apps that are not actually in-house or proprietary. There are three common ways this happens:
First, there’s app wrapping. While app wrapping can be used in lots of different ways, one way is that is if a company wants to use MAM to manage a pre-existing app made by some other entity (so not an in-house app), the company acquires the app binary directly from the developer and then proceeds to wrap, sign, and distribute the app on their own. That app could be an app that’s already being sold in the public Apple App Store—you can imagine that Apple probably doesn’t like that. (And remember that just adding MAM features to an app doesn’t make it a new, unique app in their eyes.)
Second, some MAM vendors create their own marketplace of compatible apps. Often these are just links to the public Apple App Store, but sometimes the vendors host app binaries on their own. In this case customer companies still have to provide their own iOS Developer Enterprise Program certificate in order to distribute the apps to their employees.
Third, some ISVs simple sell their app binaries directly to customer companies, which then in turn do their own internal distribution. This isn’t necessarily a MAM-industry thing, just something that goes on in general.
Keep in mind that three of these techniques depend on the customer having their own certificate, because distributing enterprise-signed apps to people at other companies is one thing that Apple is pretty clear about.
The end result here is that apps are getting distributed to multiple companies and signed using a technique (the iOS Developer Enterprise Program) that is intended more for proprietary, in-house apps.
So now what?
Clearly there are some gray areas around having multiple versions of an app in the Apple App Store and around how exactly companies use the iOS Developer Enterprise program. However, there are many MAM vendors, ISVs, and enterprise customers that are currently doing the practices described in this article. It’s not that I think that what they’re doing is bad—the issue here is that the way that people want to distribute apps and the techniques that Apple is currently offering are out of sync with each other.
So what can we do about this? Right now we can reasonably assume that Apple’s preference is that apps that are meant for a market of more than just one company (and that’s most MAM-compatible apps) should be in the public App Store, and there should be just one version.
To make this happen, if an ISVs want their app to work with multiple MAM vendors, it means building just one version of there app that works with multiple MAM protocols. This is possible (many MAM SDKs are designed so that the features lie dormant until activated, so an app could use MAM SDKs from multiple vendors), but it’s cumbersome for the ISV, and the apps can bloat in size.
If you’ve been reading some of my past articles, you’ll know that the idea of mobile app management standards is one of my causes, and that it could help solve some of these issues. And the MDM improvements in iOS 7 will make some app-level controls more widely available, which could help, too. But these are a separate discussion—what we care about here is this app-distribution gray area.
How much does Apple care about these issues? It’s easy to see why Apple wants just a single version of each app in its store: Having a bunch of different versions of an app, with different ones for users to select depending on what MAM platform their company uses, creates the dreaded F-word: Fragmentation! And obviously Apple wants people to use its App Store infrastructure whenever possible. I don’t even want to attempt to divine what Apple is thinking, but if they really cared about these app distribution issues, I’m sure they would have done something by now.
Instead, given Apple’s track record of steady enhancements for enterprise mobility management, there’s no doubt that we’ll see some sort of resolution in the future. But until then, it remains that these app-distribution issues are a gray area that we have to work around.