Kotlin Multiplatform Project Organisation Guidelines

There is a chance that you have not heard about Kotlin Multiplatform just yet as it is a relatively fresh, emerging and still experimental technology. If that is the case please take a look at the blogpost prepared by one of our team members - Sebastian from the perspective of an iOS developer. Another source of information that might turn out to be valuable is official documentation available here.

Team structure

Kotlin Multiplatform project requires well-thought team structure for the job. Most of the time we will need at least 1 developer who is capable of writing shared code. There are times though when we need platform-specific developers within the project. For example, we will need Android developer when we want to create an Android user interface and connect it to common code, or when we want to create something really dependant on the specific platform and no one created a dedicated Kotlin Multiplatform library for it just yet. In most other cases it’s enough to have a mobile-oriented person that would write common code for the project.

Estimations

The technology is really fresh so do not count on a huge list of relative tasks for Modified Fibonacci Scale at this point. The recommended approach here is to identify the smallest piece of work (aka 1-pointer) in a particular project and a big one that could be estimated for 8 points. Anything bigger should be divided into smaller parts if possible. Once you have those, you can use them as relative scale points to estimate the rest of the scope more precisely. Estimations even though performed in the Modified Fibonacci Scale allow you to check the team’s velocity after a few completed sprints (assuming a stable team and no bigger absences). Once you have tangible velocity data you can perform better budget and timeline estimations of the project to keep project stakeholders up to date.

Please have in mind that even though Kotlin is a stable, mature language - Kotlin Multiplatform framework is in an experimental phase so you can expect surprises along the way that will most probably affect scope and time requirements of identified tasks.

It’s worth mentioning that the re-estimation process should happen often in such a project as things will come up at various stages and will differently impact the project itself. This process will give you a better overview of:

• how you are spending project’s budget

• if you are getting closer to meeting project business goals,

Perform re-estimations often as a part of the risk mitigation process and part of your planning routine. It might help you to maintain a good level of transparency and stakeholder engagement in the project.

Code review process

There is a difference in Code Review process handling in Kotlin Multiplatform projects when compared to traditional projects. Here every developer in the team can perform at least part of Code Review process thanks to the fact that shared interfaces are widely used and their implementation can be double checked by anyone in the team. This can speed up the process as you don’t have to wait for the whole Code Review even if you are the only developer specialized in a particular platform present in the project.

Repository setup

The whole multiplatform project codebase is maintained in a single Git repository. Multiplatform architecture requires the proper multi-module design of the project. The modules containing shared codebase contain pure Kotlin code built with the kotlin-multiplatform Gradle plugin. The platform-specific modules are written in platform-related code like Swift or JS. Multimodule architecture requires a proper versioning strategy. Also, the fact that multiple languages and platforms are maintained in the same repository can be potentially a bottleneck in case of bigger projects maintained by the number of developers, resulting in more PR merge conflicts slowing down the development process. However, having the versioning strategy established it is possible to extract a specific module of a project to a separate repository conveniently.

You can refer to Kissme and KotlinEverywhere sample projects to check out the repository setup in action.

Project tools

• Gradle build tool

• IntelliJ Idea IDE for the main project + XCode for iOS platform module

• Kotlin-multiplatform Gradle plugin

• C-interop tool for linking iOS frameworks into Kotlin modules

Jira

Configuring Jira for Kotlin Multiplatform Project is pretty similar to other technologies, but it might be worth taking into consideration the process of Code Review which might be a bit different here and can be differently structured in Jira itself. As a part of the flow, you might want to organize two columns related to Code Review process, where one is dedicated for internal Kotlin part review and one for platform-specific code review. This depends on the project’s capabilities in terms of the team structure. The aforementioned Jira column configuration is visible in the table below:

Team cooperation

Having an awesome team might not be enough if you do not have an idea for efficient cooperation. Due to the nature of Kotlin Multiplatform projects, it is really important to work closely together to understand and grasp all parts of the application in order to be able to cooperate smoothly. If one of your team members started a task but got sick in the middle of it there is a higher chance that another team member will be able to finish the remaining work when compared to different technology projects.

In case your team is bigger, you might want to try to organize work in a way where a particular part of the team works on a particular module of the application (precise plannings might be then divided per module team). In that scenario, it would be enough to discuss contracts with the whole team and leave the rest of the discussion on the module level.

Module versioning guidelines

As a part of the project organization, you might face a challenge of finding a suitable way of versioning modules. We figured out one way to do that and you are welcome to read a bit more on the topic here.

Photo by chuttersnap on Unsplash