In this article, we are going to put some thoughts on table regarding the best architecture in kotlin multiplatform mobile. In 2023, As an android developer, we would like to work on MVVM architecture because of its simplicity, flexibility and testability. As an iOS developer, we would like to work on MVC, viper etc. In the flutter world, BLOC (Business logic components) is very famous architecture.

Kotlin multiplatform comes with cross platform development that supports sharing business logic and presentation logic in applications whether it is iOS, android or desktop. Here, we are going to further discuss which architecture we should follow and come up with a suitable architecture for KMM.

What We Want To Achieve?

In terms of architecture, There is no clear definition of matrices in which architecture to follow. In the KMM world, Architecture should be flexible enough to adopt new changes to existing codebase and should support multiple platforms in terms of testability and maintainability.

Simplicity is the key of successful architecture. We are going to avoid fancy code and on the way to simplicity.
Here are some key points:

• Maximum Code sharing whether it is business logic or presentation logic.
• Minimum platform specific code.
• Easy and better communicable between native and shared logic.
• Flexible to upcoming modifications.
• SOLID Principles

BLOC Architecture

BLOC means Business logic components based architecture which is very popular in the flutter world. Let’s break it down into smaller pieces and try to understand its matrices.

Business Logic Component

In BLOC, Business Logic Component is a simple component holding the business logic responsibilities. It involves reaction to the events, modification to the state changes by reacting to events. To understand this, let’s create a simple component and try to implement the business logic.

GalleryComponent.kt

interface  GalleryComponent {
val model: Model

fun onGalleryClick()
fun onDeleteClick()

data  class  Model(val isLoading: Boolean)
}

GalleryFeature.kt

class  GalleryFeature(): GalleryComponent {
override  val model: Model get() = Model()

override  fun onGalleryClick() {
//handle click here
}

override  fun onDeleteClick() {
//handle click here
}
}

It’s not a typical BLOC architecture if you closely look at GalleryComponent.kt or these classes. BLOC involves states, events and consumer components as well.

We would like to go with simplicity without involving the other components that can be avoided easily in Kotlin multiplatform. If you are familiar with MVVM architecture, it’s something similar to it if you replace the viewmodel with a component in BLOC architecture.
BLOC architecture fits into the KMM world as well by looking at its testability, flexibility and simplicity.

It’s a fact that BLOC comes with the adopting challenge with KMM because most of the developers come from the Android & iOS world. They would like to work more on MVVM rather than going with a new BLOC pattern having similar behaviour of MVVM. If you want to try out the BLOC pattern, I would suggest you to not use any fancy architecture library because it would be complex to maintain the overall architecture.

MVI Architecture

MVI (Model-View-Intent) architecture separates the business logic and presentation logic using intents. In MVI, intents are used to communicate with business logic.
Here, Intents received from View and Model get updated by reacting to the intents. From the bottom line, MVI comes with the cost of race conditions because It would be very complex to fix some bugs that are coming from race conditions.

In a large codebase, it’s very complex to maintain tons of intents. But I like the simplicity of MVI in its small codebase. Here, I’m already assuming you are familiar with MVI, so we continue further by skipping the examples.

MVC or MVP Architecture

MVC (Model-View-Controller) or MVP (Model View Presenter) architecture both having the same behaviour from the bottle line. In MVC or MVP, Controller or Presenter acts like a mediator which does modification to the model by reacting to the events coming from view. There is no doubt that MVC or MVP separates the business logic and presentation logic by using some sort of interactors very well.

But makes the code more flexible enough to test. But parallel, it comes with the cost of complexity of interfaces and tight coupling between view and model. Especially in a large codebase, It would be very complex to maintain the tons of interfaces. Same as above, I’m already assuming you are familiar with these, so we continue further by skipping the examples.

MVVM Architecture

MVVM (Model-View-ViewModel) architecture separates the business logic and presentation logic that removes the tight couples between each component. In MVVM, ViewModel acts like a bridge between model and view. It doesn’t have any clue of view and any direct reference to the view.

ViewModel modifies the model by reacting the events from view. If you are an android developer, you will know the MVVM very well. MVVM comes with the successful architecture matrices that any application needs. It comes with flexibility, scalability and maintainability benefits. But, again, In a large codebase, It would be very difficult to maintain the tons of states inside the viewmodel.

Which Architecture Should Be Followed?

As we all know, every architecture has its own advantages and disadvantages. But at the end, we need to have a conclusion on which architecture we should follow up on.
To deal with this conflict, You should think about key points that can help to choose the architecture as per your requirements. If you ask me for my opinion, I would suggest considering the MVVM architecture due to its simplicity.

• Is architecture flexible enough for the upcoming modifications?
• Does architecture support application requirements?
• Does architecture support testability and simplicity?
• Do architecture components are open to read but closed for outer modifications?
• How easy is it to adopt for the team?
• Is it clean and pure architecture that comes with no-third-party libraries?

Summary

In Kotlin Multiplatform Mobile, there are multiple architecture libraries in the market that come with the solution of multiple problems that exist in KMM. In 2023, Circuit architecture is coming up, BLOC architecture is coming up, Decompose is coming up, there are tons of architecture libraries that exist at this moment. But should we use these architectures?
An architecture should not depend on any architecture libraries that come up with maintainability issues.

I would rather consider using simple and clean architecture like MVVM that can easily scale and open for the upcoming modifications without being dependent on any other apis or libraries.

and here we are done!
Thanks for reading! Don’t forgot to share this and follow me for upcoming awesome articles for you.

Thank you
Mukul Jangir

Connect me on :
• Linkedin — @mukuljangir372
• Github — @mukuljangir372
• Playstore — @mukuljangir

Read more blogs