Despite good MAM solutions, acquiring and distributing apps to devices is still complex business

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).

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?

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.


Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Had a good email conversation with @gabe this morning. Thought I would share some highlights.

My suggestion to Gabe was that there is an underlying assumption that us Windows guys make. There will be XXXX apps and all this wrapping stuff will become too much to handle. In reality I suspect the number of public apps that people want is relatively small. Now that's not based on any science, just my observation.

So I suggested to Gabe that on it would be good to have a place where folks can list the public apps they want for work and share this as a community since it's not data I can find and am sure would be useful to everybody in the industry.

At the very least it would give us some insight into the scope of the problem, maturity of the market, market opportunity etc. It may also provide us insights into where the real pain points are today and how clues to where things perhaps need to head instead faster.

Anyway, that's concludes my plug to get better data on what public apps people really want for work.


Nicely laid out, Gabe. All of the current options for 3rd-party app management seem to have a variety of limitations and this is putting enterprises in an uncomfortable spot if they want to deploy 3rd-party apps across platforms. I'd be interested to hear the community's perspectives on how they see app management evolving, and whether capabilities such as app wrapping might be added to OS' in the future. It's difficult to predict if/what/when Apple, Google, Android OEMs, and others may add additional app management capabilities, but it seems like a reasonable extension for a vendor like Apple to enable enterprises to impose the same app wrapping controls (app-level passcode, restrict "open in", copy/paste, encrypt app data, etc) to 3rd-party enterprise apps. What're your thoughts?

I also have a question on the "you can talk to the ISV directly" approach. I know the article is not platform-specific, but I'm curious about iOS in particular. My understanding of the Apple iOS ecosystem is that Apple limits ISV distribution options to the standard app store or to the Custom B2B channel, and does not permit distribution of apps directly to enterprises. So, would ISVs that provide their app binaries directly to enterprises and thereby bypass the Apple App Store be violating their developer agreement with Apple?

A related question is for enterprises themselves -- I believe the Enterprise Developer agreement restricts the distribution of apps internally using the enterprise certificate to apps that have been built by the enterprise itself. Would it be a violation to take an app directly from an ISV and then sign and distribute it with the enterprise cert that is supposed to be used for internally-built apps only? Are there workarounds or other interpretations of the agreements that we're seeing customers/ISVs adopting that enable this kind of direct distribution of binaries in the Apple ecosystem?


Great points Naveed.

I also believe that end responsibility should shift to the OS platform owners in offering increased security and management extensions.

On the MAM vendors side this could make it harder to differentiate their products from the competition. I guess they would then need to concentrate on other areas of value.


Good explanation Gabe

So if you need Citrix to do the "dirty work" and reduce the complexity of dealing with ISV's .. ping me

.. chris dot fleck @

Some folks thought my job was easy ;-)


Not all MAM/EMM vendors are requiring partner apps to create special versions of their apps in order to have them be under management.

While we at MobileIron fall into the "MAM vendor can talk to the ISV directly" scenario you describe, the actual integration and distribution concern is much simpler.

At MobileIron, we didn't want to make our partner vendors fork their code and manage yet another release vehicle on potentially different timelines than their standard releases.

In addition, when this happens, it can be confusing for end users.  Which version of the app are they supposed to download?  What if they already had a different version of the app, can they migrate their data and settings?

So MobileIron's AppConnect partners (that is, the partners that include the very-simple-to-integrate AppConnect SDK in their apps) are including it in the mainstream versions of their apps.  Normally, the functionality in the SDK lies dormant.  But if the app finds itself on a MobileIron-managed device, then the AppConnect logic kicks in.

Other advantages of this approach is that this allows the app vendors to maintain a direct relationship with their customers.  Their aren't any "weird wrapped versions" of their apps out there in the world, trying to bypass the app distribution and licensing infrastructure that Apple, at least, is trying hard to control.

This is a scenario that you don't really discuss above but we think is a pretty happy medium.


@Josh, while your approach is cool, and yeah maybe we should call out that "MAM vendor talking to ISV" doesn't always end up with a separate build of the app, it does still mean that customers can only get the full protection of certain apps that happen to have incorporated the SDK.


I think the comment from Harry Labana is on the money. A lot of the question of where users are getting their apps has to do with how many public apps will users need. The steepness of the long tail in the popularity of App Store apps, especially when one discounts clearly consumer-focused apps (games, etc.) is such that one suspects that the amount of public apps that corporate users will need is not terribly large, in particular apps that will have clear additional security requirements (I may want a weather app for work but it probably does not require additional authentication policies applied). So the issue is likely to be more about corporate-focused purpose-built apps, especially ones purpose-built for a particular organization, be it by their own employees, by contractors, etc. The use of a MAM solution for those apps is obvious and the question about wrapping, for example,becomes much simpler than the cases covered in the article, notwithstanding the good points about ISV-created apps.

We at Apperian believe that the wrapping solution is preferable because it does not bloat the app with an SDK, it does not create lock-in, and it protects the integrity of the app that already exists. It also makes updates to new policies simpler without requiring a recompilation of the app with a new SDK version. As apps age, going back to the code developers or the original code base will inherently be more complicated than wrapping. In no case there is a question of user confusion when the apps are provided, with the right policies, to the right people in their app catalog, as defined by an administrative policy. If the app is or needs to be an AppStore app (and adding an SDK hardly would make an app less generic to allow bypassing of Apple's AppStore policies), the SDK approach vs the binary approach both require a collaboration with the ISV to integrate the extraneous code or to enable administrative action to wrap the app. Or, more likely, the question becomes one of providing a custom version for the enterprise, which effectively brings us back to the custom app situation above.



Yeah but:

1. Top email clients, browsers, file sharing, etc. don't incorporate any MAM SDK

2. Given variety of SDKs, how likely are ISVs to support all of them?

I think it would be beneficial for the MAM vendors to get together and spec a standard SDK, and then compete on implementation.



Great post @gabe, and some very interesting comments...

As someone who has been deeply engrained in the MAM space before it was even called MAM, let me throw out there that we are potentially looking at this with the wrong lens:  MAM done the RIGHT way is an OPPORTUNITY and enabler for app ISVs.  Done right, app vendors should embrace MAM -- and do in my experience -- when you offer them a scalable, seamless channel to get their apps into enterprises and in the hands of enterprise end-users.

But what's MAM done right?  Lots can be argued about the idiosyncrasies of the various approaches, but let's not ignore the universal underpinnings -- of course in my humble experience -- of what a user-friendly, ISV friendly and meaningful MAM solution must have:

-->  Seamless, frictionless end-user app delivery experience (none of how the bits get to the device should be an end-user's concerns and need to be hidden from them)

-->  Cannot degrade end-user native app experience (do this and users won't use the apps)

-->  Deep, meaningful, targeted set of app policies and controls (what good is MAM if the controls themselves are not broad and deep enough to be useful?)

-->  Policy enforcement in real-time (not good enough to just statically lock policies)

-->  No fundamental app source code changes or coding to an SDK or API (bottom-line, simply non-scalable and not ISV friendly)

-->  No OS patches required (not scalable, I think there is not argument there -- not even allowed on iOS)

All the above simply can NOT be accomplished by tacking on features and functionality to legacy MDM and other solutions that were never fundamentally architected to deliver all the above.  In all fairness, how could they have been?  Legacy solutions were built and architected before this "problem" in this magnitude even existed!

At AppSense, we've built a zero-friction BYOX solution (with MAM at its core) with all the above characteristics.  Just come to mobile dot appsense dot com and spin-up your own tenant in minutes to experience it first-hand and/or contact me at ajay at appsense dot com...our solution aside, we as an industry owe it to the enterprise, IT and ISVs to elevate the MAM game and offer real, user-friendly and scalable solutions.


@Danshappir 100% agree a standard is lacking or even close to forming. This will result in a lot of inertia for a while. So I agree vendors get together and figure something out, it's in all of your interests.

I find @gabes comments on IP is the wrapper disturbing. If that is any vendors IP they are dead with a simple move by the OS vendors that can create the wrapping or SDK standard.

It's hard for to come up with more than about 10 apps that people really want for work, but I do expect that will grow over time slowly. I think this growth rate even for MAM will be manageable. Question for the ISV who will the top 2-3 MAM vendors be. I expect more demand for in house mobile apps over time.

@Ajay, I'd like to understand what in your architecture makes existing MDM vendors like Citrix ZenPrise, MobileIron, Airwatch so crippled as you imply. To me it's just more policies applied to either a device or app container. Perhaps you would be kind enough to explain this in more detail so we understand how to look at the various solutions. Also I do think the fact that you are SaaS only could work against you as most brain dead enterprise will not want to use SaaS for some time. Mostly the concern is about federating ID to external SaaS, vs. something like GoToMeeting where I just use the ID the app provides. May give the on prem MDM vendors time to catch up on architectural gaps or leapfrog. Anyway curious to hear your thoughts and good to see you competing head to head with Citrix in Mobile.