Shopping in a wide variety of areas today takes place online. And user activity flows from websites to mobile applications. Therefore, often the main focus in development is on mobile platforms.



Our company already had mobile apps for iOS and Android, but the duplication of domain logic, legacy code, and the huge cost of supporting both platforms created a lot of problems. To improve manageability, flexibility and cost-effectiveness, we decided to rewrite everything. We had fewer specialists than usual in the mobile application development team in our industry, which meant that the implementation of changes would take longer.

There were two options to speed up the process:

- hire more people;
- use technology that will combine the iOS and Android platforms.

We chose the second option and started looking for the right technology to ensure the security, quality and stability of our applications. It took a while to find a cross-platform solution with UI integration. A reasonable approach was needed, and we considered Flutter and React Native.

React Native has already been used in other applications, so this technology was among the first applicants. But React Native didn't live up to our expectations due to the quality of the final product. It would be possible to create an application using Flutter, but there were problems:

- at that time there were few specialists who know Dart;
- there was already a team that wrote natively;
- Android and iOS release new versions and UX patterns regularly, and there will be a gap between a native release and its Flutter implementation.

Further research has shown that it is better not to use a common user interface between mobile platforms. Android and iOS have different UI guidelines, and maintaining a common UI sometimes takes more time than a single development takes.

A cross-platform solution was required. Having learned about Kotlin Multiplatform Mobile, we realized that this is the same approach. The technology eliminates duplication of business logic, ensuring the performance and security of its own user interface.

Using Kotlin in a Product

We started testing the KMM approach in those parts of the application that were used less frequently, such as customer agreements and feedback forms. It was important to understand whether there would be problems associated with the library.

There are two types of requests in our application: with authorization and without. Requests from authorizations are the most difficult part, so we started experimenting with requests that did not require any authorization or work with the database. In the process of rewriting modules, new user scenarios with KMM were developed from the very beginning. But the existing ones were also transferred to KMM.

Before writing multi-platform code, iOS and Android applications must have a similar architecture with modules or layers that have identical logic. In our applications, there was a similar separation of layers:

- UI (presentation);
- domain (business logic layer);
- date (data source level).

At first we were limited to moving the data layer, but then we began to move everything else, including the business logic of the application. The only parts of KMM we don't use are the user interface and platform-specific features like Apple and Google Pay.

Inside the library, we use Ktor, Kotlin Serialization and Coroutines. The Rx shell is used for platform adaptation, but in the future we plan to use only Coroutines on Android and, if possible, use Async\Await on the iOS side

To transfer the functionality of the user's basket, it was necessary to cache data from the API and we started using the SQLDelight library. With that task accomplished, we began porting more complex application features to KMM.

Advantages and disadvantages of KMM

Disadvantages that were discovered when using Kotlin Multiplatform Mobile:

- our iOS developers had to spend a lot of time learning Gradle, development environment and language features;
- harder to test on the device, difficult quality control.

The following are the identified benefits.

- Prior to KMM, basic cart-type functions required 40-60 hours of work for each platform (80-120 hours for both), not counting testing. With KMM, we can reduce the time frame to 50-70 hours for both platforms.
- We only share business logic across platforms and use our own code for each user interface. This approach provides maximum performance with a minimum amount of boilerplate code.
- Easy hire and support - KMM is powered by Kotlin, which is owned by most Android developers. And due to the proximity to JVM languages, any backend developer can theoretically work with Kotlin and KMM.
- Identical logic on both platforms significantly reduces discrepancies, which means that it reduces the cost of development and support.