Commercial mobile development projects usually leave little time and space for experimentation. Finding tools and technologies that bring tangible value to the product and let you evolve as a developer can be a challenge. That’s why a small library that enables code sharing between platforms is a nice first step you can make to learn a new technology that directly benefits a project. Kotlin Multiplatform Mobile (KMM) is that sweet spot between play and gain.
Kotlin Multiplatform Mobile is a cross-platform mobile framework for sharing business logic across platforms.
Sharing business logic across platforms brings along a host of benefits:
It’s important to understand that Kotlin Multiplatform Mobile (KMM) is just a subset of tools included in Kotlin Multiplatform (KMP). Mobile in the name indicates that this part of the technology is mobile-oriented.
Even though Kotlin Multiplatform Mobile is in the alpha stage a lot of components are stable. KMM gives developers access to many well-tested and well-tried libraries that let us:
Kotlin Multiplatform’s libraries let us implement a data access layer. You write everything once, test it once, and then you can distribute it across the platforms you need.
But not only that. If you structure your code properly, you can share up to 85% of the code between platforms. You can share everything from the data access layer by Interactors/UseCases to the data presentation layer (ViewModel).
If you are already using Clean Architecture with one of the MV* presentation patterns you’re good to go with KMM.
Some time ago one of our clients asked us to create a library that would be distributed on both Android and iOS. The library would make it easier to access the client’s API and provide a handy way to detect a decent number of events that are essential to the client’s business point of view.
This was the perfect use case for KMM. The only risk was that there were no examples of the distribution of the iOS framework built in the KMM. But if we found out that it wasn’t possible, we would still have an Android library already built.
Thanks to the ready-made libraries and the community around KMM (especially Kotlin Slack), the process of implementing this library went really well. Kotlin’s community actively helps to get a job done.
The greatest advantage of using KMM in a business setting was that we could write the code once, test it once, and distribute it on both mobile platforms.
Support is now very easy — it can be handled by only one person with just a little knowledge of the iOS platform.
The library is open source, so feel free to take a look at AudioburstMobileLibrary.
AudioburstMobileLibrary (available on Android and iOS) lets developers add the Audioburst Player and content to their app. AudioburstMobileLibrary offers easy access to the Audioburst’s Content APIs, letting developers add playlists, get information about playlists, and handle sending required events to the API without any effort. Integration is convenient and simple to increase engagement.
Check out how we helped Audioburst build their mobile apps.
One of the best things about this technology is that you can start playing with it in a variety of ways.
You can build a simple app that will let you share code between the platforms. There are a lot of KMM samples on the web on how to do that. You can also create and distribute a library that will wrap some logic used in your project.
Another option is to take some part of your currently developed app and transform it into a multiplatform app. If your app is modularized, then introducing KMM will be very easy.
A library written in Kotlin Multiplatform can be distributed as a Multiplatform library that will be consumable in other Multiplatforms projects (that is more common). But you can also distribute the library separately on the platforms you want to support.
Once you have a KMM-based library, you can distribute it locally and online. The distribution is done via plugins that let Android and iOS apps use the libraries.
Distributing Android libraries is easy. There’s no difference between distributing KMM-based libraries and Java/Kotlin/Android libraries.
You just need to choose one of the repositories it will be available on (please remember that JCenter is not an option anymore). Build aar/jar file alongside POM file and distribute it. We’ve chosen MavenCentral and here’s our configuration.
For more information, read a great article by Stream about the distribution process to MavenCentral.
But iOS is a little bit different. The main framework’s repository is Cocoapods, and this is the place where we would like to be.
To get there, you need to build an XCFramework (it’s a type of framework that contains both ARM64 and x86 builds that will let you run on real devices and simulators) from your codebase, prepare a podspec file and distribute it there.
At the moment there are no official plugins that will let you build an XCFramework. But it’s hardly a problem because it’s where the KMM community shines.
For example, Georg Dresler built a great plugin that lets you build an XCFramework with just a single gradle task (createXCFramework). This plugin will also let you build Swift Package if you would like to.
So how does Kotlin Multiplatform Mobile look in action?
We’ve conducted a few tests to see how apps perform and weigh with additional KMM libraries.
You might be curious about the overhead of an iOS library when you integrate it into your project. Our library is using a few other libraries that potentially should increase its weight significantly.
We did some tests and while the XCFramework itself is pretty “fat” — it weighs ~50 MB — it stops being a problem when integrated into a standard iOS project. The final .ipa file is just 1.5 MB heavier with this framework included, and that’s before Apple’s optimization when uploading to AppStore.
Even though it’s new, Kotlin Multiplatform Mobile has already lodged itself firmly into the tech stacks of some of the globally recognized brands.
Prodicle, Netflix’s app for video production, relies on Kotlin Multiplatform to build business logic that runs across platforms. Netflix chose KMM to improve product delivery times using multiplatform architecture.
Memrise is a language learning mobile app with over 40 million registered users. Memrise uses Kotlin Multiplatform to have one business logic shared across platforms. Before implementing Kotlin Multiplatform, the company had to debug the code between platforms, which burned time and productivity.
The team at Leroy Merlin needed a solution to rewrite legacy code that generated extensive management costs. Before deciding on Kotlin Multiplatform, the team considered React Native and Flutter, but both technologies didn’t fit in with the internal company requirements.
Ultimately, Leroy Merlin rewrote the code in Kotlin Multiplatform to eliminate the duplication of business logic and the resulting overhead. Using Kotlin Multiplatform didn’t impact the app’s performance, and it works as fast as the company’s natively written applications
My short answer is: yes. However, because Kotlin Multiplatform Mobile is still in the alpha stage, you need to be ready to face some issues, especially with tooling.
Beyond that, there are a couple more aspects you need to know about.
Kotlin Native is using a different memory model, which makes concurrency a little bit more difficult, especially at the beginning. Read more about concurrent mutability in Kotlin’s official documentation.
From my experience, how concurrent mutability looks like in Kotlin Native is not as difficult to understand as you may think. It’s helpful to first better understand in which thread your mutable state is getting mutated. The good news is that JetBrains is aware of the problem and is preparing a new memory model for Kotlin Native.
Another thing to remember is that there are still no mocking libraries available on all platforms. Currently MockK, for example, supports only JVM. In my opinion, it’s not a big problem. You will end up writing a little bit more code, but generally, there are a few good reasons to stop using mocking libraries and favor passing interfaces instead of implementations around your apps. Read why Android’s engineers suggest better alternatives to mocking.
In my opinion, the benefits you get from Kotlin Multiplatform Mobile far outweigh the drawbacks. You get less code to maintain, reduced development time, and native performance, on top of all the other benefits listed out in the article.