After discovering a new interesting technology or framework, you will probably start asking yourself how to integrate it into an existing project. That’s because, the possibility to start with a blank canvas is rare (not impossible, but rare).
This is also the case for Kotlin Multiplatform (I’ll call it KMP in the rest of the article).
When starting a new blank KMP project it is easier to have a mono-repo structure like this:
However, existing projects most likely don’t have a mono-repo structure. And making a refactor to achieve this structure can be extremely difficult for time or management constraints. But KMP is built around the concept of sharing as much non-UI code as possible, and it is possible to start sharing a little piece of tech stack. Then, this “little piece of tech stack” will be served to the existing projects as a library.
Where to start from is subjective and it depends on the specific project, but there are some parts that better suit this topic. For example, all the boilerplate code (constants, data models, DTOs, etc), that is boring to write and is more error-prone. Or it could be a feature that centralizes the source of truth (e.g. if a field is nullable or not) because with a single source of truth there will also be a single point of failure. Or it could be some utility or analytics helper that every project has.
An important thing to take in mind is that all the features chosen for sharing must have the possibility to be extracted gradually. That’s because, during the evaluation process of KMP, it is better to make a final decision without using too much time. For example, it will be not a good idea to start sharing the entire network layer because you will risk ending up with useless work if KMP is not the right solution for the project. Otherwise, starting with some small features like a DTO or a data model will require less “extraction time” and it will leave enough time to work on the architecture needed to have a Kotlin Multiplatform library in an existing project.
For example, at Uniwhere we have decided to start with some DTOs and after validating the process, we have migrated all the others.
The architecture of an existing project with Kotlin Multiplatform will look like this:
There is a repository for every platform:
- a repository for the KMP library;
- a repository for the Backend;
- a repository for the Android app;
- a repository for the iOS app.
As mentioned early on, the KMP code is served as a library. The compiler generates a .jar for the JVM, a .aar for Android, and a Framework for iOs. The .jar and the .aar can be published in a Maven repository. A Framework can be published in different places: for example in a CocoaPods repository, in the Swift Package Manager or with Carthage. Since I’m familiar with CocoaPods (and because we are using it at Uniwhere), I’ve decided to stick with it.
Publishing for Android and the JVM
The amount of work needed to publish a JVM and an Android library to Maven is pretty straightforward, thanks to the Maven Publish Plugin. Only a few lines of configuration on the build.gradle.kts file, are necessary (here I’m assuming that you have already configured a Maven repository since it’s not the scope of the article to explain how. Otherwise, you can use a local Maven repository on your computer that does not require any kind of configuration):
After that, it is possible to build and publish the KMP library with the
./gradlew publish command (or with
Then, it is possible to pull the library on Android:
and on the JVM project:
Publishing for iOs
On iOS things are harder.
Pack for Xcode
On newly created KMP projects, there is a Gradle task, named
packForXcode, that automatically builds the framework and places it in a specific build folder.
This task is automatically called by Xcode when the iOS (or macOS) application is built.
The task uses the configuration of the iOS project to define the build mode and the target architecture.
The build mode can be
DEBUG while the target name depends on the architecture which we are building for. The real devices use the Arm64 architecture, while the simulator uses the host computer architecture which in most of the cases is X64 (at least until when Apple Silicon will be sufficiently spread).
And this is the problem of this task!
Since the aim is to publish a framework to be used by an existing project, it’s impossible to know a priori which architecture is necessary or the build mode.
CocoaPods Gradle Plugin
Another way to build a framework from the KMP code is using the CocoaPods Gradle Plugin. This plugin builds the framework and places it inside a CocoaPods repository that will be added as dependency on Xcode (The plugin can be used also to add other Pod libraries on the native target).
To start using the plugin, some configurations are necessary:
Then, during the build, the Podspec file (a file that describes the Pod library - it contains the name, version, and description, where the source should be fetched from, what files to use, the build settings to apply, etc) is generated starting from the information provided in the
The Podspec contains also a script that is automatically added as a build script, called every time the iOS application is built, like
Unfortunately, this script has the same problems as
packForXcode, because the configuration and the target architecture are computed during the build phase.
So, also the CocoaPods Gradle Plugin can’t be used.
The solution is to use a Fat Framework that contains the code for every required architecture. To build it, there is a Gradle task named
FatFrameworkTask that can be customized to meet the specific needs.
The first step is building a custom Gradle task to build a debug version of the Fat Framework.
This custom Gradle task, named
universalFrameworkDebug is necessary to provide some customizations to the
FatFrameworkTask. After some cosmetic info, like the name and the group of the Framework, the required architectures and configurations must be provided. In this case, the required architectures are x64 for the simulator and arm64 for the real devices. The configuration instead is
The last needed information is the destination of the framework.
The destination will be a CocoaPods repository that at the end is a git repository that contains the framework, the debug symbols, and a Podspec file.
The git repository uses branches and tagging for handling debug and release versions. The debug versions of the Framework are pushed directly to the develop branch without any tagging. The release version instead is pushed on master and tagged.
For more information about setting up a private CocoaPod repo, I suggest you give a look at the official documentation.
After pushing the changes on git, the Pod library is ready to be pulled by XCode. On the
Podfile of the iOs project, is necessary to specify the Pod library with the information about the source and the version.
For debug releases, it is enough to specify to pull the latest version from the
For production releases instead, it is better to specify the required version number.
The last step is building another Gradle task, to build a release version of the Fat Framework.
The script is the same as the previous one, with the exception that the target is changed from
And, that’s it! Finally, it is possible to start using the KMP library on iOS as well.
However, there is room for improvement and I wanted to minimize the effort of publishing. All the steps for publishing the framework in the CocoaPods repository can be automated with a Gradle task.
publishDevFramework task will build the framework and automatically publish the changes in the develop branch of the CocoaPods repository.
First of all, the task changes the working branch and then builds the debug framework.
Before publishing the new version, the version name inside the Podspec file must be updated.
And this is done automatically by the task.
And at the end, the new changes are committed and published into the develop branch of the repository.
To publish a release version of the Framework, there is the
This task is very similar to the
publishDevFramework task. First of all, since it is a release, the master branch will be used.
Then, before publishing, the commit will be tagged to specify the version name of the release.
And, that’s it! When the KMP library is ready to be published, three tasks can ben called:
publishto publish JVM and Android artifacts;
publishDevFrameworkto publish a debug version of the iOs Framework;
publishFrameworkto publish a release version of the iOs Framework.
As shown in this article, the process of integrating Kotlin Multiplatform in an existing project requires more work on the architecture side. That’s why is preferable to start sharing a feature that can be extracted gradually.
The framework to follow is:
Start little and then go bigger.
By starting little, it is possible to validate the process with a “contained” effort, and then, after the validation, it is possible to go bigger and start sharing more and more features. For example at Uniwhere, we started sharing the DTOs and after validating the process, we decided to share also the persistence layer with SQLDelight.
All the code that I showed in this article came from a sample that I’ve published on GitHub (if you are interested only in the custom Gradle task, click here). This sample is composed of an Android app, an iOs app, and a backend that share some common code via a Kotlin Multiplatform library.
Update: I’ve grouped all the tasks mentioned in the article in a Gradle plugin! To know more about it, give a look to this post.
I’ve spoke about this topic in a talk in the Kotlin Dev Room at Fosdem 2021.
Here’s the recording of the session:
and the slides: