Kotlin Multiplatform: Usability for Companies

What’s Kotlin Multiplatform?

Kotlin Multiplatform(KMP) is designed to simplify cross-platform development by enabling code sharing across Android, iOS, web, and desktop platforms. This approach can significantly reduce development time and costs, as well as ensure consistent functionality and performance across different environments.

Learn more: https://kotlinlang.org/docs/multiplatform.html

Benefits for Companies

Even though WELT news app is not using KMP, we have been keeping an eye on it. We are interested in it because of the following reasons:

1. Reduced Development Time: Share common code for networking, data models, and business logic across platforms.
2. Cost Efficiency: Minimize the need for platform-specific teams.
3. Maintainability: Easier to update and maintain a single codebase.

Obviously, some advantages are common for the other cross-platform frameworks, but an explicit thing is that developers don’t need to learn extra languages such as dart, nodejs. We already have Kotlin experts working on Android and backend. Meanwhile, they can still use their familiar frameworks.

Potential Risks and Issues

We believe KMP can make our lives easier, but still some risks we have to consider:

1. Learning Curve: Requires iOS developers to be proficient in Kotlin as well and understand the multi-platform ecosystem.
2. Platform-Specific Challenges: Certain platform-specific features may still require custom implementations.
3. Tooling and Ecosystem Maturity: While improving, the ecosystem and tooling are not as mature as some other frameworks, which could lead to integration challenges.

Whether using KMP usually depends on iOS developers instead of Android guys. iOS devs are more familiar with Apple ecosystem specifics, which is easy to ignore in the other cross platforms. I think that’s one of the reasons why those platforms didn’t succeed, so many iOS guys still insist on using native development.

KMP is walking on a different path, it’s developing from shared foundation to UI layer, not reverse. Thus, the iOS side still has chances to develop with native UI frameworks such as UIKit and SwiftUI. It’s more acceptable for iOS.

For some startups, can only hire Kotlin developers to serve multiple platforms, while big companies also can use the KMP shared common library. That’s why I’m optimistic about this.

Why we have not used KMP for production yet?

However, we still have a critical reason not to adapt it. KMP only can generate Objective-C code so far. It’s a real drawback for KMP. I believe Objective-C definitely is a nightmare for many senior iOS engineers when calling it a swift project. It lacks a lot of necessary suger syntax and is not safe. Jetbrains announced that the native swift support is working in progress, but there’s no exact release date.

Skie

Therefore, we explored a workaround as well. We found a compiler plugin called Skie. It is designed to improve the iOS development experience within Kotlin Multiplatform by enhancing Swift interoperability. Traditional methods of integrating Kotlin with Swift via Objective-C often lead to limitations, but SKIE modifies the Xcode Framework produced by the Kotlin compiler to retain essential language features.

Learn more: https://skie.touchlab.co/intro

Benefits

1. Enhanced Swift Interop: Enables direct Swift-Kotlin communication, overcoming limitations posed by Objective-C intermediaries.
2. Maintained Language Features: Preserves important Kotlin features that are otherwise unsupported when using standard interop methods.
3. Ease of Integration: Works seamlessly with existing Kotlin Multiplatform projects, requiring minimal changes to the distribution and consumption of frameworks.

Disadvantages:

1. Compatibility Concerns: SKIE is compatible only with specific Kotlin versions (from 1.8.0 to 2.0.0). Using incompatible versions may lead to build failures.
2. Lag in Updates: New SKIE versions supporting the latest Kotlin releases may have slight delays, potentially impacting project timelines.
3. Limited Preview Support: SKIE does not generally support preview versions of Kotlin, which could be a limitation for developers wanting to experiment with cutting-edge features.
4. Performance: It doesn’t replace objective-C code, just add a swift layer. Thus, it extends compiling time and causes some potential issues of running performance.

Trial in Hackathon

Though KMP looks not perfect so far, we‘re still willing to try it. We attempted to apply it in our Hackathon recently as a sharing library. (Learn it more here) It’s a nice experience as we can test the power of KMP in practice. I would talk about it from these four aspects:

Usability

We set up the framework for iOS as an SPM package, so we can directly depend on it like the normal SPM dependencies. The experience was so good that sometimes I didn’t realise we were using the library from Kotlin. I could effortlessly import the module to our project and easily call the functions.

Nevertheless, we still found some inconvenience in the duration. I always check the documentation comment via the option key and go to the definition of function or property via the command key. But in the header of KMP, you cannot find the original comments, there are only objective-C definitions with swift aliases, like the below image:

It looks like not readable. Besides, for example, if you want to navigate to the declaration of KAIPromote type, it's not allowed.

Moreover, we also invested much time in type conversion between the two platforms. We found sometimes the Array in Swift lost the element type as Any from Kotlin's List.

Flexibility

I would say the expect/actual feature in Kotlin makes KMP more flexible. It's like an interface, developers can complete their own implementation on different platforms. We used this feature for getting UUID from Android and iOS, respectively. I believe there are more scenarios we can apply. For instance, if we have a shared library that needs to access Rest API. We cannot only use `ktor` to implement it but also define an `expect`, use `retrofit` on Android and use `AFNetworking` on iOS. Amazingly, KMP can support CocoaPods to implement this thing. You can complete all things in Android Studio.

Architecture

If we intend to dependency inject in terms of different environments, clean architecture would be a good choice. We defined many interfaces of user cases in the library. iOS side can flexibly choose if use it or implement by ourselves for any functionalities and layers.

Performance

Since we introduced a new feature, it’s hard to compare the difference of the CPU and memory between with KMP and without. However, a direct feeling was that the build time was quite long. Therefore, I deliberately recorded the compilation time.

Whether with derived data or not, the build with KMP took more time. I think the reason is that we hybrid-compile Swift and Objective-C. The shared library doesn’t include too much logic, but the build time increases explicitly.

In short

In the Hackathon, We fully felt the charm of KMP. It helped us save much time on creating the base module for two platforms. Besides, iOS and Android share common APIs, no more conflicts of logical design. We enjoyed using it in practice, and also are looking forward to Kotlin resolving the current issues we are facing.