The recent release and news around Android Kotlin seemed an awesome time to write a blog about the importance of developer choice.
Perhaps the number one question raised when presenting Appdome to folks is this - "Will Appdome work with my app if it is built in [Native Xcode, Android Studio, React Native, Cordova, Xamarin, Kony, etc.]?" This question is a critical one. Still, I want to unpack it a bit. My goal is to help newcomers and business teams assess the role of Appdome in achieving their mobile strategies.
Integrating services into mobile apps has always come with dependencies. The reason is simple. SDKs don't work with all development environments. Specific standards often have to be added to apps for APIs to work. In all cases, methods and protocols used by the service and the app can conflict, limit and constrain implementations. Developers are left to sort out and overcome the gaps, sometimes achieving success and other times facing delays and failure.
Development environments also change, evolve, and emerge all the time. Kotlin is to Java what Swift is to Objective-C. Developers like having choices and want the freedom to choose the environment in which to build great apps. Other artists might choose the brush or musical instrument to produce their work. Developers choose the environment to build their apps. By having that choice, they enjoy their work more and produce better apps, faster and more consistently for the rest of us. Organizations that have produced several apps over time are likely to have built apps in many environments. That's because over the life of building mobile apps, organizations switch to newer, more modern and powerful environments to create even greater apps.
Now consider the challenge of an organization or ISV that wants to migrate several if not 100s of mobile apps to a new way of doing something. In this scenario, this "something" could be anything like modern authentication, cloud identity, modern management, mobile threat, etc. At a single app level, this work is difficult. At the multi-app level, the myriad of development environments, methods, and protocols used across these apps makes migration operationally daunting.
I saw this recently at the Oktane'18 customer conference. Several organizations explained to me that they built mobile apps with username and password workflows. These organizations never imagined they would need or want to migrate these apps to cloud identity. Now, they do. And they're faced with the difficult task of retooling their apps to accommodate this new class service. They need help.
In other cases, the service the organization or the developer wants inside the app holds back the implementation. Like a musician who doesn't want to buy a new guitar, only to find out his amplifier is incompatible or underpowered for his new instrument. Developers, who migrate to newer more modern development environments don't want to be held back by the constraints of the services needed inside apps. The "gotcha" often faced by developers is that their apps are ahead of the services they seek to implement. I see this situation a lot in enterprise management use cases, where the SDK used by the EMM or MAM vendor doesn't quite reach the newer development environments like Cordova, ReactNative, etc. These organizations too, need help.
With this in mind, take a look at our recent patent. The technology we've built allows services to be added to apps at the binary level. That means, our process of adding services to Android and iOS apps occurs after the development of the app itself. This means that the developer is free to choose the environment he/she wants to build an app. It also means that our technology can be leveraged to bridge the gaps that exist between the service and the app itself. Once bridged, features are exposed for the benefit of all developers using the same method, protocol or environment and service. And, even if the developer decides on a new environment tomorrow, the same feature set will work inside the app. Neither the organization or the developer is held back. That's the advantage of Appdome.
We hope to continue to see a proliferation of new, more modern and powerful development environments to build great apps. We'll do our part to continue to enable choice and the freedom to build great apps in environments developers choose. It's good for the developer and your business.
Recently I presented on no-code integration development during the Mobile+IoT Summit. Download the slides to learn more about Making Apps Enterprise Ready.