Is Apple ruining everything for mobile virtualization? Or are they saving us from it?

We're on the cusp of having several different virtualized mobile phone offerings on the market from VMware, Cellrox, and Open Kernel Labs. While these solutions have each have their own strengths and weakness, they all face one huge challenge.


We’re on the cusp of having several different virtualized mobile phone offerings on the market from VMware, Cellrox, and Open Kernel Labs. While these solutions have each have their own strengths and weakness, they all face one huge challenge: there’s very little chance that Apple will ever allow iOS devices to be virtualized, which means that all these products will only work with Android phones. So is it Apple’s fault for spoiling the the mobile virtualization party for everybody? Or is Apple saving us from it?

Mobile virtualization and its alternative, dual-persona mobile app management, both have the same goal: to safely insulate and control the interaction between corporate and personal apps and data on mobile devices.

How virtualization achieves separation

Mobile virtualization products achieve this by having completely separate user environments for work and personal apps. The techniques range from full type-1 hypervisors to type-2 hypervisors and virtual profiles. You might be thinking, “There’s no way a phone would ever have enough power to do this!” But there are a few reasons why mobile virtualization isn’t quite as resource-heavy as it might seem. First, the obvious one: Android phones are becoming more powerful. While virtualization was a stretch a few years ago, there’s just more horsepower to spare now. Second, despite running multiple OSes or profiles, the multitasking scheme is usually the same as with an ordinary phone—there’s still only one foreground app running at any time, so the device doesn’t actually have to do that much more work. Third, all of these products utilize guests VMs that are the same OS as the host, and in the case of “lighter” solutions, much of the OS is shared between the virtual environments anyway.

It’s easy for IT to manage apps and settings, because they can have full control over the corporate environment, just like a regular corporate device with mobile device management software. And while a locked-down environment might be unacceptable for personal devices, it’s okay here, because the user’s personal environment can remain completely unmanaged, if desired. IT can keep the list of approved apps as restricted as needed. These work apps are free to do their thing in the secure corporate environment without any app wrapping or other modifications, because all the dangerous user-installed apps are in the personal environment, and any communication between the two can be controlled as well.

Sounds great, right? We know that we have to deal with this being Android only, but there are some other issues, as well.

First, you can’t just install a guest VM on any random phone—all of these solutions require devices with highly-customized versions of Android. Since most users wouldn’t like the idea of IT replacing their whole OS—even if it did contain a personal environment that IT couldn’t touch—mobile virtualization solutions depend on cooperation from the device manufacturers themselves. The idea here is that phones will ship with the virtualizable version of Android already in place, and then IT can use special APIs in the OS to provision and manage the corporate virtual environments. (In this respect, mobile virtualization solutions are much like other OEM-specific MDM APIs, such as Samsung SAFE and 3LM. OEMs release devices with the APIs, then MDM providers create the management products that can interface with them.)

Alternatively, users could buy the device on their own and then create a work VM to surrender to IT to manage with traditional MDM, instead of giving up the whole device. (That should be one of our FUIT posts: “Don’t want your company to manage your personal device? Give them a VM, instead!”)

Second, since mobile virtualization will be dependant on certain compatible devices from specific OEMs, the overall choice of devices will be very limited. That hot new Galaxy S III in your hands? Yeah, that won’t work when your company decides to adopt one of these products. Instead, we’ll have to wait for the mobile virtualization vendors to create partnerships with the OEMs. All this does not bode well in a world where users are accustomed to using any device they want. There is one area will this will be okay, though: corporate-issued devices. In high-security or compliance-bound industries, a device that contains a freewheeling personal environment that IT doesn’t manage is certainly an attractive alternative to a Blackberry or a completely MDM locked-down Android or iPhone.

Third, there are still a few issues with IT having full control over the work environment. For example, if one app needs to have a very high level of security, then unless they’re doing some management at the app level, then the entire environment will have to live under that high level of security. So that 16-character password that protects sensitive financial data? You have to put that in when you want to do a quick glance at your inbox, too. Cellrox in particular can address this issue by setting up multiple linked work personas, with different levels of security.

Finally, we’re just barely seeing this stuff come to market. VMware has been working on Horizon Mobile for four years, and it’s just now about to have its first limited release, but not in the US. Cellrox is coming soon, I’m told, and Open Kernel Labs seems to still be a ways away from its dual persona product.

The dual-persona MAM approach

I’ve written quite a bit about the concept of managed and interconnected corporate apps on unmanaged devices, so if you’re not familiar with the concept, check out the article Defining dual persona MAM: Corporate and personal stuff side-by-side on the same device for some background information.

The main advantage here is that MAM works on any device, including all the phones your have in their pockets right now. All the security features are on the app level, which means that corporate data can be safe on completely unmanaged devices (This is just one extreme, of course. There’s a whole MAM to MDM spectrum between this and locked-down managed devices.)

Another big thing that MAM has going for it is its prevalence. There are dozens of companies that offer some form of app management, and a growing handful that provide all (or almost all) of the components of a complete dual-persona MAM environment. Most important is that all this is shipping today, while we’re still waiting for any mobile virtualization availability to even be announced in the US, let alone ship.

But dual-persona mobile app management has its own big catch, too: you can’t let just any random app be part of your system. Generally, there are four sources for apps:


  • Apps from the MDM provider itself: These will often be email clients, secure browsers, and file syncing apps.
  • App wrapping: This allows MAM systems to incorporate apps from third-party vendors. The problem is that you have to get these through a special arrangement with the vendor and sign them yourself. App wrapping doesn’t work with apps users download from public app stores.
  • MAM SDKs: These allow all the management hooks for an MAM system to be incorporated in homegrown corporate apps.
  • Select public apps. Some commercial developers may partner with an MAM provider to make their publicly-available apps compatible with corporate MAM.


What about Apple?

Even after years of hipsters and bloggers saying that Apple has sold out and jumped the shark after every new product release, Apple continues to have very tight control over its products. This means as much as anybody might hope, mobile phone virtualization vendors still little chance of ever touching iOS, and mobile virtualization will remain Android-only. 

The vendors excuse this by saying that we don’t need virtualization for Apple because it’s more secure. But even with iOS, you still have to find a way to keep corporate and personal apps and data separate, and for right now, MAM seems to be the only way to do it. But what about Android being less secure? There are a lot of phones with older versions of Android that have fewer security features floating around, but this is more of a concern if you’re trying to manage the whole device using MDM, and less of a concern with MAM. To varying degrees, MAM vendors argue that managed apps can be “self defending.” In other words, it doesn’t matter if you have an old, insecure version of Android, because you can build most of the features you need right into your app, instead.

Is there a place for both?

Let’s recap the arguments: mobile virtualization doesn’t require any special apps, but you’ll be limited to just a few Android devices, and on the other hand, dual-persona MAM is open to all devices, but not all apps.

Ultimately, there’s probably a place for both solutions. Personally, I’m a bit torn. The gadget geek in me thinks the idea of a virtualized phone is cool, but I’d be hesitant to give IT control over the whole device, even if they can’t touch the personal side. For MAM, I like the idea that any phone can be completely unmanaged yet still access a rich world of corporate apps and data, but I also acknowledge that getting apps into the system in the first place could be difficult.

Which scheme would you prefer for your own device? How about for your users? And do you think Apple is ruining mobile virtualization for us, or saving us from it?


Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Apple is definitely saving us from "mobile virtualization". Mobile Virtualization should not be in the same discussion as BYOD.  The concept of BYOD is that corporate users can use personal devices to access corporate data.  To offer a BYOD program you have to be able to offer support for multiple platforms including Android, iOS, Windows Phone, etc.  Why would I purchase a separate mobile virtualization platform that could only handle a select few Android devices when my MAM/MDM solution can support all platforms?  Even with corporate issued devices IT wants to have a choice of what devices they want to offer users and will not go out of their way to choose a specific Android model just so they can use a mobile virtualization platform.  Mobile Virtualization is a cool solution in general but in real world practicality it is useless.  I work in the Public Sector which is highly regulated.  These agencies have to support iPads & iPhones more then any other platform because iOS is seen as more secure then Android and they do not trust that BlackBerry with stay in business or keep up with technology trends.  MAM/MDM has challenges getting the apps from different sources but most organizations are only worried about Email/Contacts/Calendaring, Secure Web Browsing (micro-vpn) and file access/editing.  These core apps are included with any true MAM/MDM solution.  Outside of these core productivity apps the majority of apps are web based which can be securely delivered with a MAM product's secure browse functionality & SSO.  I have customers that have been able to get access to popular apps raw app file (ipa/apk) without much effort.  If they are willing to pay for a site license or buy multiple licenses for their mobile users these companies do not have issue providing the raw app file so they can wrap it.  A lot of times the MAM vendor will navigate those discussions with the third-party.

In summary, mobile virtualization was a cool concept 5 years ago when the market was empty, but the problem has been solved in much more efficient ways today.  VMware may release their mobile virtualization platform to the US but as we saw at VMworld they already announced Horizon Mobile will support app wrapping for iOS and I would be shocked if they didn't offer it for Android soon after.


I agree with Scott. I think Apple is saving us from "mobile virtualization". I haven't seen either solution listed in the article, in fact this is the first I've heard of virtualizing a mobile device, and I thought I was current with technology :(

I think MAM can probably handle the separation of personal and business more efficiently than running mobile vm's side by side. Being able to wipe specific areas of a phone and/or tablet device, a function of the MAM software, is also more appealing to a BYOD user, who may be concerned with IT managing 'too much' of their phone/tablet. Finally with respect to BYOD, I agree with something Jack said about device choice. Giving a user options for devices isn't really a BYOD program, it's a 'hey these are the approved phones/tablets that we use here, pick one" program.

In closing, there are some great MAM technologies out there now that if I were tasked with implementing a more secure mobile solution I would be seriously considering. I don't think I would be waiting for future releases of mobile virtualization.


Why would Apple want to enable a world where you can switch away from their primary interface that they have spent boat loads of money on to encourage developers to build for to most likely a crappy IT locked down environment that put's the user experience last.

If anything I think the OS vendors Apple, Microsoft etc. can build in native MAM capabilities over time and commoditize the market and bring order to it and offer their developer eco system an enterprise market...


hi Jack

I think that VMware's argument in favor of mobile virtualization is entirely sound. Enterprises build and certify applications against specific operating system not against devices, so the ability to manage a virtual machine and develop and support applications against a known platform has significant value. In a BYOD environment the user is free to upgrade to a new OS at any time, at that point IT loses the standard baseline that it has developed the application the gains, and can no longer provide support and effectively. With a mobile hypervisor (type I or type II) the enterprise has comprehensive control over the virtual machine even though the host operating system may change over time.

But of course this only works if you have the cooperation of the device manufacturers who will permit the installation of the appropriate kernel changes necessary to install the hypervisor, something that Apple are very unlikely to do. Hence the fallback solution for VMware is a secure container running on iOS.

This really puts others in the position of having to say that mobile virtualization should be adopted where it can be and secure containerization adopted where it must be. Which means that as Mark points out, anybody wanting to manage BYOD environments today should look at mobile application management as the pragmatic way forward.

The leading questions are, as ever, center on how much traction will the hypervisor-based solution gain in the marketplace. As we both know, the challenge is much greater than it was with server or desktop virtualization. Where anyone can install ESXi, Xen,Hyper-V, etc. on their own PC or laptop, rooting a smart phone is far more difficult and has a much lower possibility of success. For all practical purposes the phone has to be shipped with this capability built-in which means partnerships deep into the supply chain are needed before success can be assured; a process that takes significant time.

The wildcard here is Microsoft,  will it support the virtualization of Windows Phone 8. From a hardware perspective the opportunity looks good, the base hardware specification looks to be more than capable of supporting virtualization. And it goes without saying that if Microsoft can find a way to charge for this service it will. Certainly,to my knowledge they have made no positive margins in this direction. If however Microsoft, with its enterprise focused, work to get behind the virtualization of Windows Phone 8, it could be sufficient to establish mobile hypervisor's as a mainstream technology.

Nevertheless , As Harry pointed out no vendor will do anything that will permit a competing operating system onto their hardware platform. To do so would be suicide.