Workspace One Send connects to Intune MAM, but Microsoft and Apple could make it easier

Enterprise mobility management still faces some long-tail issues.

Back in May, VMware blogged about Workspace One Send, an app that connects Workspace One apps to Intune MAM-enabled apps. There was a little bit of confusion about how it works, as well as how it compares to BlackBerry Bridge, a similar solution, so I talked to VMware for more details.

I’ve already spent a lot of time covering relevant background issues, including:

The bottom line is that a lot of customers want to connect the Office mobile apps (which use the Intune MAM SDK) to apps that use competing MAM SDKs. This is where Workspace One Send (as well as BlackBerry Bridge) comes in.

Workspace One Send operates entirely at the app level, with no MDM dependencies. It incorporates elements of the Workspace One SDK, as well as the publically available Intune MAM SDK, so it can operate both in the Workspace One container and the Intune container, allowing users to transfer documents back and forth without exposing them to the rest of the device. Send also supports Microsoft Information Rights Management and Azure Rights Management Service, as another option for protecting documents.

To use Send, you must be both a Workspace One and Intune customer. The Send app is available in Google Play and the Apple App Store. For now, VMware has artificially constrained it to just work with their Boxer email app, but this could easily be expanded to work with any Workspace One-enabled app.

When using the iOS version, users have to tap through several steps, bringing the Send app to the foreground in the process; the Android version has fewer steps, as Android allows the app to remain hidden in the background.

I haven’t precisely counted the number to taps it takes to get back and forth in Workspace One Send and compared it exactly to BlackBerry’s version—what matters more are the reasons why EMM vendors are compelled to make these types of apps in the first place. To quote from my previous article:

“Having to deploy a hub app between the two ecosystems seems like a bit of a kludge, [...] but of course in software, that’s just the way things are sometimes. And not to look a gift horse in the mouth—instead, this really underscores that the whole situation around proprietary MAM SDKs and app wrappers is quite challenging.”

Both Apple and Microsoft could do more to address this situation. Google gets a pass for now, as they have put an admirable amount of effort into making Work Profiles on Android enterprise the most BYOD-friendly device-based MAM framework we’ve seen yet.

On the Apple side, I’ve written multiple times that iOS MDM really needs to catch up with BYOD expectations in 2018. Enrolled devices can just use the existing managed open in frameworks that work with any app, skipping Send and Bridge.

Of course, there will still be devices that don’t get enrolled, or organizations that want multiple layers of protection. For this, Microsoft could do more to make Intune MAM and the Office apps more extensible.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Via email, a reader sent this comment and gave permission for it to be published:

"And another area is on the horizon were Android takes the lead over iOS: Multi-user support. The upcoming Android P promises to bring multi-user management into Android Enterprise management. This feature is especially required in retail and POS situation, where a single device is shared by several employees. Add-ons like AirWatch's and MobileIron's shared device support don't do the job anymore, because they can't remove access tokens from modern authentication apps like Office 365 anymore between user sessions. Let's see how Apple reacts to the upcoming competition in business use cases."

This reminded me that we haven't spent that much time talking about this—Android calls this the "ephemral user," for corporate-owned, single-use devices

Adds yet more fuel to the arguments that I made in these two articles: