Anyone even passively paying attention to the EMM space is no doubt familiar with the terms App Wrapping and SDK's (both of which are types of Mobile Application Management). Jack Madden did a good job summing up their similarities and differences, but one question looms large in my mind: How are people getting these applications?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
To sum up what Jack wrote, the basic use is the same in that software from an ISV is made to work with the application management solution of choice. How that's accomplished is different, though. Wrapped applications require access to an application's binaries so that the MAM vendor can "wrap" their management code around it and repackage it as an internal application (signed with an enterprise certificate). This can be done with any app as long as the ISV is willing to license the binaries. The SDK method, on the other hand, essentially means that the MAM provider works with the ISV to create a special version of the app that is built with the hooks in place to leverage the MAM's SDK. That app can then either be distributed internally via enterprise certificates or made available in the public app store.
Now that that's out of the way (you can learn more by checking Jack's articles about MAM), back to my original question: How are people getting applications for these MAM solutions? I ask this because there seems to be an increasing amount of complexity in just how applications are handled for mobile devices. I come from a Windows background, and I'm used to a world full of MSI files where my options for deploying them are install them directly, stream them, package and deliver them with SCCM, or RDS (which is really just one of the other ways). I appreciate this because I remember a time when it wasn't that simple, and I think we might be at that stage with mobile applications.
Let's look at the process to get a fictional application called "Brian's Pivot Table Viewer" on to our devices. For this example, let's assume that it's available in the public app store and that one or two users love it so much that IT has decided to deploy it across the board. There are several options that are worth breaking out to illustrate the situation we're in (or that we have to look forward to).
Buy it from an app store
This one is simple enough–each user is instructed to browse to the app store and purchase the app on their own. This is the ultimate hands-off approach, simple, but unmanaged. Of course, many organizations are simply letting this happen, but if you're in the market for MAM, you've probably already written this off.
There are other options that leverage the public app store infrastructure, at least from Apple. Apple offers both a Volume Purchase Program, which allows companies to purchase applications en masse, or to deploy company-specific internal applications via a feature called Custom B2B. With the VPP, companies can purchase licenses for an application, after which they are given a list of redemption codes and URLs. These URLs are then distributed to the users either via email, a web or intranet link, via an MDM solution, or via the Apple Configurator.
Of course, this is fairly easy, but unless the app is designed for use with an MAM solution, it's still relatively unmanaged approach.
You can talk to the ISV directly
Another option for companies is to talk directly with the ISV. That means finding the publisher of Brian's Pivot Table Viewer (probably Brian), then approaching him on the side to see if your company can get a hold of the binaries for the app so that you can wrap it yourself. This approach only works with some MAM vendors, and, of course, relies on the ISV being on board with this plan. You'd have to work out a licensing arrangement, and that arrangement would only be for your specific situation. If you reach an agreement, you'd have to wrap the app yourself and distribute it to the devices with your enterprise certificate.
The MAM vendor can talk to the ISV directly
The other approach to this is to rely on the MAM vendor to make the connection. If the MAM vendor reaches out to the ISV, they could get a version of the app that is pre-certified to plug into the platform. Perhaps this app lives in the app store as "Brian's Pivot Table Viewer (MAM Vendor X version)," or it could exist in the B2B store as a custom-designed app. It could even be folded into the product from the beginning like an email or calendar app would be. This is a nice approach because the MAM vendor is doing the dirty work, but it relies on the MAM vendor to make things happen. Companies like Citrix, AppSense, Good, and Bitzer Mobile all use some aspect of this method, but deployment methods differ between them. What happens when the app is updated, though? Will there be a lag between when the public version and MAM-specific versions are released?
So there's three ways to actually incorporate an application into your mobile ecosystem, some of them managed, some of them not so much. For each of these ways, there are also different methods of actually distributing the application. It's conceivable that a company could have some apps that come directly from the ISV which are installed with an enterprise certificate, other apps that come bundled with the MAM platform, and others from app stores. Apps could live in the public app store that are designed to work with a MAM platform (and that users might have sort through to find the one for their appropriate MAM), or they could also come via the VPP/B2B programs from any one of the sources. On top of that, you could also create your own app store that links to internal and public apps. Yikes!
The complexity of this situation can, I'm sure, be overwhelming to many companies looking to do something, especially when you add in different mobile platforms. Will there ever be a resolution to this? How would it manifest itself? Standard hooks into wrapped applications that work across the board? I can't imagine that would come to pass, especially since the IP of each of these solutions is in how the apps are wrapped, sealed, and/or delivered. I'd hate to see a situation where Brian's Pivot Table Viewer is aligned only with one MAM solution, which might force a company using a different MAM solution to choose the inferior "Wesley's Pivt Table Vewr." Maybe one cocktail of methods will rise to the top–I just hope it doesn't stay this way forever.