In my previous blogpost I mentioned a couple of challenges that I encountered in previous projects where we were developing apps for internal use within an enterprise organization. These apps were distributed using an EMM platform, and developed using a cross platform tool: Xamarin.
At the time, the status quo was that EMM tooling and cross platform development frameworks were evolving at a different pace, which meant that EMM platforms (at least the ones we looked at) were not prepared for apps built with a tool like Xamarin. Read the blogpost for further details.
This is a very interesting and fortunate development since this means that we will be working towards an industry standard for API’s through which enterprise apps can make use of EMM features. After all, most of the features are the same across vendors, but each has their own technology to solve these issues. This meant that if you wanted to use features like Single Sign On across applications, data protection or dealing with network connectivity, the EMM framework of choice would be very invasive to the app. If ACE is widely adopted, this is no longer the case, and enterprises will have the freedom to change EMM vendors without much impact on their apps (other than having them wrapped again and re-distributed).
Not only developers benefit from this, but end users as well. Having a standardised and easy setup process, onboarding in an EMM program is a much lower barrier. I’ve seen the UX of some of these vendors and they’re sometimes confusing and unpleasant. A standardised way to handle this is a welcome addition.
At the moment, ACE is still mostly just an initiative, and I think that the standards need to crystallise a bit more, but there’s already a Dev Center with a couple of (proposed) standards. Let’s have a look…
What we see is that most of the standards default to leveraging the out of the box facilities in the OS. I.e. if the app uses these frameworks and API’s, and the EMM vendor also conforms to these standards, you should be safe. For iOS 7+, the Managed App Configuration standard is referenced, which makes use of the EMM API’s that Apple has built into iOS such as the Apple MDM Protocol.
A configuration setting sent to an app for example, would be stored in the NSUserDefaults dictionary named “com.apple.configuration.managed”. Reading a setting would then be as easy as this:
NSString *keyValue = [[[NSUserDefaults standardUserDefaults] dictionaryForKey:@"com.apple.configuration.managed"] objectForKey:@"keyName"];
Or, in Xamarin speak:
var keyValue = NSUserDefaults .StandardUserDefaults .DictionaryForKey ("com.apple.configuration.managed") ["keyName"] .ToString ();
For Android (Lollipop+), you would make use of App Restrictions.
Well, you can read the rest of the specs on the Dev Center page.
ACE and BYOD
In general, I think it’s a good idea to default to built in OS features for tackling security requirements like this. One drawback is that for some (or most, actually) features, you have to assume that your users are on a recent OS version. With iOS, that’s 7+, which is usually not that big of an issue because of the fast adoption of new iOS versions. But for Android, some features are introduced in Lollipop. Certificate authentication in a web view for example, was not accessible for a developer in previous versions. And that might be a big issue if your enterprise has a BYOD policy, and you’re dealing with all those older versions out there. But, you have to start somewhere, so this is a matter of time before this is sorted out. That may take quite a while though, so if you’re going to follow the ACE strategy, you might want to think about providing compliant devices to your users instead of them bringing in their own old and crappy Android phone.
What about cross platform development?
A big advantage of Xamarin is that we have the ability to share code across platforms. With these EMM and App Config features however, we’re going back to platform specific implementations. This calls for a component or set of plugins that can help in abstracting these implementations. This would of course be a Xamarin specific component in my case, but the same would apply if you use Cordova or Titanium.
I’d be interested to know if Xamarin is already working on an abstraction like this, or otherwise I’d be interested in starting such an initiative. If anyone wants to help, let me know 🙂
Another very big advantage is that – if developers and EMM vendors follow these standards – app wrapping or use of a proprietary EMM SDK would become unnecessary. And this is good news for cross platform developers. No more worrying about whether the wrapper is aware of the Mono DLL’s inside my Xamarin.Android app, etcetera.
One very big shortcoming is that the ACE site only proposes solutions for iOS and Android. Where’s Windows?! In the recent releases of Windows Phone, Microsoft has added support for several EMM features to the OS, so surely there must be some guidance for implementing SSO, SAML, Settings, etcetera in Windows Phone, Store and desktop apps.
This is something that I would like to add, or see added, to the standards.
All in all, I’m very happy with the ACE initiative and I hope to see more vendors join the club. Microsoft should definitely chip in, and other cross platform tool vendors as well. I applaud Xamarin, AirWatch and the others for showing the way forward.
This can make a lot of difference for enterprises who struggle with purchasing and contracting an EMM vendor, concerns about lock-in, and limitations or obstacles in their app development.