Perhaps the largest consideration when evaluating Kotlin multiplatform for your projects, teams, and organizations is whether or not you want a fully cross-platform solution, or want to share models and logic but stick to native UI. As was discussed previously in the Sharing logic, not UI section of this chapter, Kotlin multiplatform doesn't generally touch the UI layer of your application. As such, building applications with Kotlin multiplatform still requires knowledge of native platforms and the building of native UI for each of those platforms. This is in stark contrast to solutions such as React Native or Flutter, in which the business logic and UI are both defined in common code and shared across the various platform targets.
The difference in shared UI versus shared business logic impacts the team structure as well. With any cross-platform solution, knowledge of the native platforms is useful. However, with Kotlin multiplatform, it's truly critical. Without native code for the UI layer and integration of shared Kotlin code, there will be no application. React Native, Flutter, Xamarin, and so on present the possibility of the entire application being written in shared code. For example, you could build a mobile development team consisting of primarily JavaScript developers that leverage React Native to build your apps, and it's likely that the majority of these developers would rarely need to interact with native platform tools or code. When considering Kotlin multiplatform, React Native, Flutter, or any other cross-platform solution, it's important to think about your current team structure, skills, and long-term hiring strategy.
As you consider how to build a team that is leveraging some form of code-sharing or cross-platform solution, it's important to consider the skills and technologies required in relation to your current team, along with potential future hiring needs.
With Kotlin multiplatform, each application will still require native code and tools. For example, your web team can still use familiar frameworks such as React and Redux while consuming shared Kotlin code. Your Android and iOS developers will still likely be working within Android Studio and Xcode as they integrate the shared Kotlin code and build out native UI components. If you have several existing platform development teams, Kotlin multiplatform might represent a low barrier-to-entry solution with which to start sharing code among those existing teams. This is quite different to a solution such as Flutter, which is a much more all-or-nothing approach to cross platform.
Because of the reliance on existing native tools, code, and expertise, Kotlin multiplatform is a relatively low-risk option for experimenting with code sharing. Integrating Kotlin multiplatform code with an existing project is quite simple, especially for Android and JavaScript, and can be done in very small increments with little to no impact on existing code. This makes it very easy to try out within a team, as well as easy to replace if it doesn't meet your needs. These two traits significantly lower the operational risk involved when compared to solutions such as React Native and Flutter.
Beyond the conceptual differences between Kotlin multiplatform and other cross-platform solutions, there are more tangible differences and limitations in the development ecosystems of the various approaches. In the next section, we're going to discuss the current state of the Kotlin multiplatform ecosystem and what limitations this may entail.