This is the first post in 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.
When you think of software development kits (SDKs) or 3rd party libraries, it’s a nice thought to think that one SDK or library will fit all apps. SDKs provide a set of tools, code samples, and documentation that are designed to inform developers on how to add new services or features to apps. But the diversity of apps, how they’re built, the frameworks used to build them, etc. have exploded and continue to proliferate. An SDK or library has to work inside this increasingly growing universe of native or non-native mobile apps. The gap between SDKs, use cases, and apps grow daily and will continue to grow. The ability to solve for gaps becomes critical.
Imagine a team of people who want to build an SDK. No doubt, these are intelligent, capable and dedicated professionals. From the start, these people need to make tradeoffs. They have to decide where to start, what to document first, what platforms to support, what features to expose, etc. They will create their SDKs in a similar fashion as a product is borne. They will start with v1.0 and, over time, the version number will grow with each new use case. From the start, more will be left out than in. It will take time to evolve; more time than it takes for new use cases to emerge. Gaps naturally exist.
Now, imagine another team of people who are building native mobile apps. They too will have to make tradeoffs. They have to decide what platform to write first, what framework to use, what features to build, etc. Often, they will choose to implement SDKs and APIs for external services critical to the app’s use. As they add services, they will discover that features, frameworks, and services often come into conflict with a net new SDK that needs to be added. Just as often, they will discover that their customers want to use the app in a way that has yet to be supported by their app or SDK vendor. Again, gaps exist.
A major challenge developers face when attempting to implement mobile app security using SDKs, open-source libraries, or specialized compilers stems from the fact that these methods all rely on source code and require changes to the application code. And as a result of that, each of these methods is explicitly bound to the specific programming language that the application is written in, and are also exposed to the various programming language or package ‘dependencies’ between those languages and frameworks. In software development, a dependency is a broad term used to describe a program or piece of code that relies on another program in order to run or to perform a function. For instance, if Program A requires Program B to be able to run, Program A is dependent on Program B (and vice versa this makes Program B a dependency of Program A). For a real-world example of this problem, check out this Stack Overflow post by a developer who needs to build code obfuscation into an iOS app where there are multiple dependencies between React Native (a non-native framework) and Objective C (a native coding language). Because there is no built-in library in the iOS project that will obfuscate React Native code, the developer needs to use an external package (dependency #1). Furthermore, that external package has an additional downstream dependency on yet another npm package in order to obfuscate the JavaScript code (dependency #2).
In addition to all of the operational, resource, manual coding, and timing issues that this entails, dependencies may result in a significant loss of control for the mobile app developer.
If those third-party libraries become deprecated, no longer supported, or cease to stop working for any reason, the developer may find themselves scrambling to find another solution or may suffer functionality loss in their apps.
Appdome Bridges Compatibility Gaps Between Mobile Dev Frameworks, SDKs & Apps – Automatically
At Appdome, we understand that these gaps are serious business. They impact the developer and the enterprise user equally. That is why we are dedicated to solving the gaps and serving critical use cases with instant implementation options anyone can use.
Functionality and compatibility gaps will always exist in mobile app development and mobile app security. It’s folly to think that all platforms, frameworks and feature sets will merge into one. In fact, we think diversity and choices are what make the mobile economy so exciting and vibrant. Our goal is to allow customers to bring the best of what’s out there together, and overcome these inherent gaps between apps, frameworks and SDKs – all without coding changes.
Every day, Appdome’s product is used to solve literally thousands of gaps between SDKs and apps for enterprise customers. Keep reading other blogs in this series to learn about specific use cases where Appdome’s no-code DevSecOps platform is used by mobile developers, security teams to automate mobile app security and eliminate framework incompatibilities for any iOS or Android app.
- Native and Non-Native Differences
- VoIP applications inside UEMs
- Code Obfuscation for Native and Non-Native Apps
- Jailbreak Prevention and Rooting Prevention
- How to Eliminate Framework Dependencies in Data at rest encryption
- How to Handle Webview Incompatibilities in Mobile Apps
- Secure Remote Access without an Enterprise VPN
- Why Mobile SDKs Are Not DevSecOps – and never will be
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.
