This post is part of a series of blog posts discussing the common challenges mobile developers face when implementing mobile app security features or 3rd party mobile SDKs into Android and iOS apps.
Bridging Framework Incompatibilities in UEM SDKs – No Coding
Implementing UEM (formerly EMM) SDKs in mobile apps is extremely difficult, even for the most skilled team of mobile developers. I’m referring to mobility management SDKs like VMware (AirWatch), Microsoft Intune, MobileIron, IBM, BlackBerry, etc. These SDKs are designed for corporate IT departments to distribute, manage and secure the mobile apps that employees use in the workplace to access corporate resources using a mobile device. And the difficulty of these SDKs has nothing to do with the product itself per se. The nature of the job these SDKs perform, and the fragmented and hyper-variable environments in which they’re developed and deployed, introduce inherent complexity into the process. No matter how you slice it, UEM SDKs are extremely resource-intensive to build, and complicated to deploy and manage in mobile apps if implemented manually – ie: by modifying source code. And since mobile apps can be developed in different frameworks (native, hybrid, and non-native, there are very important framework dependencies that will determine if the SDK is at all compatible with your app. Here’s a good 3rd party article on the subject by mobile technology analyst Jack Madden.
When developers and ISVs implement these SDKs manually (ie: by modifying the source code of the mobile app), the release cycles are always very long (6 to 9 months or more per OS, assuming they have the source code). This blog will explain in technical detail why this is the case, and will also explain how Appdome solves this problem for all major UEM SDKs.
UEM SDKs alter Mobile Apps In Fundamental Ways
UEM SDKs usually affect the structure of mobile apps in fundamental ways. They alter how users authenticate, how data is processed, stored, saved, and sometimes erased (a process called ‘wiping’). They affect the path data travels from source to destination (app to the server) and how the data is handled while it’s in transit, in use, and at rest.
These SDKs must encrypt data before it’s stored and decrypt it when it’s read. There are encrypted file systems, with nested folders living inside apps that use different methods for writing, storing, managing, and retrieving data. Oftentimes, these apps require optimizations and adjustments to the underlying crypto model, or different crypto libraries altogether depending on the nature or purpose of the data and the environment within which the data lives. For instance, a DoD app used in battlefield reconnaissance has different data characteristics and security requirements than an e-commerce app used to buy detergent (not to diminish the importance of the latter).
In addition, UEM SDKs alter the methods and the paths data travels from the app to the backend. Sometimes traffic is sent over VPN tunnels that use protocols not well-suited for the app’s design. For example, some UEM VPNs can only route traffic over the TCP protocol and don’t offer settings to change this. You don’t need to be a networking guru to know that if you try to send latency-sensitive traffic (like VoIP, messaging, or interactive chat) over a TCP tunnel, calls will drop or the call will experience significant jitter or latency, all resulting in quality issues.
UEM SDKs sometimes intercept user flows and insert new workflows in the user’s path, sometimes using ‘webviews’ that take the user outside the app experience, and then back in again. Ever been in a mobile app doing your thing, enjoying the beautiful design, clicking on big blue perfectly sized buttons that look like delicious cotton candy. Then you click on a link and all of a sudden you’re staring at a pre-historic webform that looks like it was written circa 1994, where you need to scroll for 10 seconds just to see the right half of the input field to enter your name, then back again. It uses .0005 point micro-font that require bionic bifocals to read. Yes, we’ve all been there.
It’s possible that you’re using a non-native app built in React Native (or Ionic, or Flutter, or pick your hybrid app framework du jour), and you’re dealing with a bad implementation of the SDK that didn’t anticipate or could not process the Webview that would be thrown at it. Or maybe the developer thought they were using a version of iOS where Apple had introduced WkWebViews (instead of UIWebview) and the experience would be more ‘responsive’. Or perhaps the developer didn’t read page 147 of the SDK Reference Guide where it stated that a Cordova plug-in was required if the app used non-native libraries (or a React Native, Swift, or Flutter plug-in). Or literally hundreds of other things that could go wrong when a non-native web browser is shoe-horned into a native app (because mobile apps don’t have browsers). Just doing a simple search on stack overflow for ‘Webview problems in mobile‘ and you’ll find a very diverse range of problems mobile developers grapple with when dealing with webviews across different mobile dev frameworks.
All apps are built differently. And when it comes to managing or securing apps, the underlying structure of the app and how that app functions and behaves often drives different requirements, techniques and methods for delivering new functionality inside the app (especially functionality that can be intrusive to the user experience – such as security and management).
Framework Dependencies and Manual Plug-ins
A big problem arises when UEM SDKs attempt to reach hybrid or cross-platform mobile apps with their standard ‘native’ variants of their SDKs. Most SDKs typically come in native Android and iOS variants first (designed to integrate and plug into natively built apps, that use native libraries, written in native languages). None of these exist in non-native apps where the only thing that’s native is the shell in which the app is packaged. To achieve anything close to compatibility, functional parity, (or just to get the app to work) with UEM SDKs requires significant _additional_ human effort (ie: more manual coding on top of the manual coding you’re already doing to implement the SDK, more development time, multiple plug-ins, sometimes even an entirely new SDK. Sometimes the plug-ins don’t even exist yet, and need to be created by the SDK vendor in the middle of your dev cycle). Now to be fair, the Webview problem I describe above is not a UEM-centric problem. But these kinds of SDKs, due to the very nature of the job they perform, are more susceptible to the framework dependencies and incompatibility issues that cause the problems I just characterized.
UEM SDKs (and the humans that implement them) must deal with an incalculable set of variants, permutations, and scenarios (some of which are not known or even knowable at the time they code the SDK to the app). So yeah it’s hard work and a lot of it. Any slight variance in the implementation can have drastic impacts on the user experience, app performance, or the security posture of an organization. There are many framework differences that need to be navigated carefully in order to ensure a good user experience or even a functional implementation.
These differences require a contextual and adaptive understanding of the app in which the SDK is being implemented; this cannot be achieved with a one-size-fits-all approach inherent in most UEM SDKs. Furthermore, the sheer number of permutations of methods, behaviors, and interactions among mobile app features and components is far too large and complex for a human being to hard-code into the app by hand – no matter how great the developer. This is a job destined for automation, which is exactly how Appdome helps UEM SDKs overcome framework dependencies and reach all apps consistently. The net result is a rapid, consistent, secure implementation for UEM SDKs into any iOS or Android app (for every app framework in existence, with zero manual work). This enables UEM customers to extend their existing UEM deployments, increase the functionality of their apps, and improve their mobile user experiences – all with less work.
No-Code Solutions For UEM SDKs
When you upload an app to Appdome, our AI algorithms learn the structure of the original app, its capabilities, as well as the framework used to build the app (including its libraries, resources, methods, logic, etc). The same is true on the services side (ie: the new capabilities or SDKs you want to add to the app). If a mobile service or SDK is listed on Appdome, that means Appdome’s AI algorithms have been ‘trained’ on how to generate and assemble the right codesets to implement the SDK and all its features and components into any iOS or Android app in less than a minute. Appdome also knows how to overcome gaps, incompatibilities, platform and specific framework dependencies, or behavior variations that exist between the mobile app, the SDK/API/service, and the native OS. This all happens in real-time – accurately and consistently, without any SDK plug-ins and without dependencies on developers or ISVs to change the app. This is how Appdome completes in seconds what it would take an entire team of mobile developers and other highly skilled resources months to complete using manual coding.
When you build an app on Appdome, the end-result is a natural set of interactions that do not alter the app’s design, interfere with the native OS function, or spoil the user experience.
Check out this video to see how to implement the Microsoft Intune SDK into an SAP enterprise app in minutes without any coding.
If you’d like to see a demo of any use case or feature discussed in this blog, I’d be happy to show you a demo personally. You can drop me a line directly at alan@appdome.com or Request a Demo by clicking below.
