Why we need Kotlin Native
Mobile development has historically required development on 2 or more distinct platforms and toolkits
- iOS: (Objective C, Swift, Xcode)
- Android: (Java, Kotlin, Android Studio)
Abstracting logic and sharing common code that is reused for different purposes is not a new concept, it is the history of modern computing. By comparison, iOS and Android are just over 10 years old and still in its infancy.
Why we need a cross platform solution
Both iOS and Android platforms are sufficiently complex that it takes years for engineers to be considered experts in a single platform. Mastering each platform requires knowledge of 2 officially supported programming languages, knowledge of the hardware, platform SDKs and various supporting libraries. Organizations that want to simultaneously support an iOS and Android application must support a minimum of 2 teams. As such, it’s very uncommon to have engineers whom are experienced in both platforms. This leads to further fragmentation as the two teams attempt to maintain feature parity, respond to defects while still leveraging the strengths of each platform. The ability to selectively share common logic across platforms with minimal friction while leveraging the intricacies of each platform enables teams to focus their energies on delivering features and value to the only stakeholder that truly matters — the users of your app.
The User Experience
From the users perspective the mobile experience is everything they can see and interact with on the mobile application. Users don’t know or care what language, framework or which web services the application is using. The user’s interaction with the app is via the screens, notifications, platform and interactions with hardware such as Bluetooth, sensors and cameras. Both Apple and Google have invested heavily in their respective platforms and differentiating them. Each annual update brings functionality, APIs and targets such as watches, bendable phones, televisions etc.
What the user experiences is thus UI and its integration with the native system SDK, performance and other capabilities such as offline support. Any mobile framework that applies restrictions, additional abstraction on top of the native platform leads to friction and prevents developers from leveraging the full platform and leading to either a compromised user experience or additional development overhead. What makes an application unique and brings value to the user is areas the user interacts with such as UI, notifications and integration with the rest of the system. Layers of the application that sit behind the UI such as business logic, REST endpoints, caching, JSON serialization and dependency injection has minimal value in being platform dependent.
The Ideal Platform
- Should integrate into the existing platform build toolchain and CI infrastructure
- Should leverage the underlying platform API and language with minimal friction particularly the user facing components such as UI and Notification
- Should integrate seamlessly without introducing the overhead of an additional runtime
- First class tooling support in terms of IDE support, compilers, lint checks
- Community and 3rd party library support
Flutter is to apps what Silverlight was to the web. It compromises of own libraries, language and rendering. It was developed by Google independently of the Android team. Flutter utilizes the Dart programming language. Flutter aims to develop a common development platform and SDK by writing directly to view layer and providing its own SDK, UI widgets, runtime and programming environment. Flutter’s primary goals are to replace not augment the Android and SDK framework. The primary use case is for new greenfield projects that want to target multiple platforms with a consistent UI. Although Flutter can potentially deliver a high performance experience the ability to deliver consistent look and feel across platforms for complex apps that utilize the distinct features of each platform is challenging. Coincidentally one of the most popular and discussed Flutter apps, Hamilton does not utilize the Material or Cupertino guidelines
Dart: Niche programming language that is not commonly used outside of Google. Existing developers will need to be retrained, hiring prospects challenging
Flutter SDK: Aims to replace, not complement the native SDKs
- State of React Native 2018 — Discussions of threading model, Android RecyclerView
- React Native at Airbnb — AirBnb announced sunsetting of Airbnb. Many of their issues were related to integrating React Native in a brownfield app
The primary disadvantages of React Native
Bridge: Any communication between the Native and Mobile is completed over the bridge. This can lead to complexity in terms of complex integrations and introduces a performance penalty.
Dependencies: React Native introduces many dependencies which leads to issues such as inability to support x64 on Android. https://stackoverflow.com/questions/48732351/react-native-app-64-bit-version . The React Native is a large platform and introduces many limitations on the native platforms that leads to issues with security and maintainability.
The primary advantage of Kotlin Native vs other competing platforms is the GUI, sensors, notifications and everything that is unique and specific to each device will be developed in the native language and runtimes without restriction. Compared to Flutter and React Native solutions Kotlin Native reduces barriers and avoids compromise.
On Android the common module is assembled into the final APK using the native build tools. On iOS the common module is compiled to a single native library and assembled into an app utilizing the native build toolchain and native IDEs. Similar to React Native, Kotlin Native will attempt to leverage the underlying platform and enable developers to define the seams on a feature or component basis which feature should be developed in platform specific vs Kotlin Native. Kotlin Native provides the option but not obligation to share code across platforms.
The history of mobile computing is to share code and stand on the shoulders of giants. As mobile phones become more powerful and ubiquitous in our everyday lives, the types of mobile applications we build will continue to grow in size and complexity. The option to selectively share code across platforms will become more essential in the future. Kotlin Native is still early beta and not without issues and challenges but regardless it is shaping up to be the most pragmatic solution for cross platform development in the future.