Auto Added by WPeMatico

Leroy Merlin Case Study: Building Customer-Facing Flagship App with KMM

Leroy Merlin helps people all around the world improve their living environment and lifestyle by helping them design the homes of their dreams and make them a reality.

The Leroy Merlin mobile app helps customers search for products, shop online and find their nearest store. The Russian branch of Leroy Merlin has stores in 64 cities, and 1.5 million people use the mobile app monthly.

Visit the Kotlin Multiplatform Mobile portal to find more case studies from different companies!

The decision to use Kotlin

Prior to 2018 Leroy Merlin already had iOS and Android mobile applications for customers. Both applications had native implementation with domain logic duplication and very old legacy code with huge management costs. In order to make them more manageable, flexible, and cost-effective, the company decided to rewrite them.

Our applications were almost identical and responsibility for rewriting them was given to the mobile team that consisted of 6 iOS and Android engineers who at that time didn’t share much of their experience with each other, and a tech lead to manage the entire fragmented process. This was not a scalable flow. Moreover, we had fewer engineers than a typical mobile app development team, which meant it would take us longer to implement changes

We had 2 options that could help us to speed up the process: The first was simply to hire more people, and the second was to use a technology that would allow us to share knowledge and expertise between the iOS and Android teams. We chose the second option and started to look for a suitable technology, bearing in mind that the safety, quality, and stability of our applications are of paramount importance.

It took us a while to find a cross-platform solution with UI integration. This was a critical point because we wanted to use a fully shared approach. We considered both Flutter and React Native. It was May 2019 and KMM was not widely known, and so we did not yet consider it.

We also have another team of engineers who develop an internal mobile app for company employees. They use React Native in production, so that was the first technology we looked at. But React Native didn’t match our expectations because of the code quality. When scaling the application, React Native loses quality, so we disregarded this option.

Of course, we could make an application using Flutter, but as we looked deeper into this technology we discovered that this approach would have two major problems. The first problem was hiring, because very few people know Dart. This meant that the project would not be scalable because we would have problems if we needed to write some native code.

The second problem, which is ultimately more dangerous, is that both Android and iOS constantly have new releases, new versions, and new design patterns, and there would more than likely be a gap between the native release and the Flutter implementation of it. It’s okay for use in internal applications, but we cannot use this approach for the customer-facing flagship app.

Some further research revealed that we would be better off not sharing the UI between mobile platforms. Android and iOS have different UI guidelines, and it takes more time to support this difference than to just develop the UIs separately.

We understood the benefits of a cross-platform approach, and it was important to use it because other teams had already been building internal applications with a shared codebase, and our team intended to exchange insights with them. So we looked for a suitable cross-platform solution.

The first time we heard about KMM, we understood that it was the very approach we had been looking for. It excludes business logic duplication while providing the performance and safety of a native UI.

Finally, we had a technology that allowed us to share business logic, make platform-specific UIs in accordance with the guidelines, and simultaneously ensure speed and quality of native forms. And it can be written in Kotlin, which is native to the Android platform. We realized that this is exactly what we needed for our project.

Migrate your existing project to Kotlin Multiplatform Mobile module by module!

How KMM was used in the product

Given that KMM was a new technology we started testing it with the parts of the app that were used less frequently, such as customer agreements and support pages, to see if any library-related problems would arise. We have two types of requests in our application, with and without authorization. Requests that require authorization are the most difficult part, so we started experimenting with the requests that required neither authorization nor cache space. In the process of rewriting modules to KMM we developed new user scenarios with KMM from the very beginning, but existing scenarios were transferred to KMM when they needed to be refactored.

Prior to writing multiplatform code, both iOS and Android applications should have a similar architecture with modules or layers that have identical logic. Our apps had similar layer splits:

  • UI (Presentation)
  • Domain (Business Logic Layer)
  • Data (Data Source Layer)

We only moved the data layer at first, but then we modified our process and started to move everything else including Domain use cases. The only KMM parts we are not using are the UI and platform-specific features like Apple and Google Pay.

Inside the library we use Ktor, Kotlin Serialization, and Coroutines. We use the Rx wrapper for platform adaptation because our platforms use Rx, but we are planning to use only Coroutines on Android in the future.

In order to improve the performance of the user’s cart functionality, we need to make it fully independent without any synchronization with the website. This means that there is a lot of work to do with the cache. So to perform this task well, we’ve started using the SQLDelight library for API caching. Once we are done with this task, we will be transferring more of the app’s core features to KMM.

Pros and cons

The pains we found using Kotlin Multiplatform Mobile:

  • Our iOS developers found it was necessary to spend a significant amount of time familiarizing and acquiring skills for working with Gradle, the development environment, and the language features.
  • It’s more complicated to test on a device, and the QA process is generally more complex.
  • The iOS Interop, which currently is Obj-C.


  • Before KMM, core features like the user cart required roughly 40-60 hours of work for each platform (80-120 hours for both), excluding testing. With KMM we can reduce the timeframe to 50-70 hours for both platforms. So using KMM we expect to significantly decrease development time.
  • Performance and quality of native forms. We only share the business logic between platforms, and we use native code for each UI. This approach gives us the greatest performance with minimum boilerplate code.

Easy hiring and support. KMM works on Kotlin, and it’s very easy to find developers for Kotlin because almost every Android developer already knows it. And due to its proximity to JVM-languages, almost every backend developer can work with Kotlin and KMM too.

Identical logic on both platforms significantly reduces divergence. We actually originally had a problem in addition to business logic duplication. Sometimes we had different implementations for a feature on each of the two platforms. We released our iOS versions before the Android versions. Sometimes we decided to implement some fixes in the logic after the iOS release, and this occasionally resulted in us implementing these fixes in Android only and forgetting about iOS. Of course, this was not a rule, but it happened from time to time. KMM helps us avoid these problems because if you fix something, you fix it on both platforms at the same time. But beware: this also means that bugs will appear on both platforms.

Suggestions, tips, and tricks.

Let’s say you have decided to use KMM (a good choice). But there are iOS developers in your team who are not familiar with Kotlin and don’t know how to use it. You will definitely need to help them adapt to the new language. We found that creating a Kotlin and KMM knowledge base greatly facilitates this process. Each time you face a problem with something (deploying, adding libraries, etc.), make documentation and share it with all the developers, then they will be able to refer to it later and work out how to do things.

An important point is not to force KMM on teams, especially the iOS team. You need to explain that with KMM, iOS developers will not stop working with the Swift or Apple ecosystem. We have developers who work with KMM and developers who don’t. It is important to explain that Kotlin doesn’t mean you favor Android. This is a shared decision. These explanations are important because, if you don’t clarify these points for the iOS developers, they may reject this approach.

Another problem with iOS is the local Kotlin environment. When you want to add a dependency on your local KMM module as a Pod through Cocoapods integration, it means that you have to build Kotlin Native code for this Pod. This increases the complexity of building projects, affects iOS developers who don’t want to work with multiplatform, and increases the project build time. We fixed this problem by changing the Cocoapods Podspec file. We changed the source of our Kotlin library from Git to URL with a production-ready zip archive with Apple Framework. And now iOS developers work with KMM like they would with any other Cocoapods prebuilt dependency.

Possibly the most important advice we have for people is that they shouldn’t be afraid to be among the first, because without risk there is no reward. KMM is a very stable technology with a huge community, so if you want to save time and make application development easier, try Kotlin. But remember that reliability and safety are top priorities, so try to make the changes gradually, and start with parts of your application that are not critical.

Visit the Kotlin Multiplatform Mobile portal to find more about cross platfrom development!

Continue ReadingLeroy Merlin Case Study: Building Customer-Facing Flagship App with KMM

Down Dog Case Study: Building 500K Subscribers App with KMM

Down Dog is the innovative start up that brings a studio-like yoga experience to your mobile device. With Down Dog you get a brand new yoga routine every time you come to your mat.

Unlike following pre-recorded videos, Down Dog won’t make you do the same workout over and over again. With over 60,000 different configurations, Down Dog gives you the power to build a yoga practice you love!

This app brings yoga to over 500k subscribers on both Android and iOS, with over 100k users completing a practice daily. The app has 200k reviews on iOS and over 100k on Android, with an average rating of 4.9 on both platforms. And what is this incredible app built with? Kotlin Multiplatform Mobile!

Visit the Kotlin Multiplatform Mobile portal to create your first cross-platfrom application with Kotlin!

The story behind Down Dog

In 2015, having worked at Google for three years, co-founder of Down Dog Benjamin Simon started to feel frustrated with the size of Google and his inability to drive progress forward as an individual programmer. He had recently become obsessed with yoga and was in the middle of finishing a yoga teacher training program. It suddenly dawned on him that the logic for yoga sequencing they were learning could be put into code in order to generate semi-random sequences much like an instructor does, which was the seed idea for Down Dog. So, with an old college friend, he began to work on bringing the practice of yoga to people’s mobile phones.

The project

It has now been about six years since the first prototype. Certain parts have remained unchanged; the same original set up of a Tomcat backend server still runs on AWS that communicates with a PostgreSQL database. The first version was a prototype that only existed as a web app (written in TypeScript). When they then committed to Down Dog, that prototype was thrown out and they built the first iOS app using Swift, which launched in August of 2015. In March of 2016 the Android app followed, which was written in Java. Around September of 2016, the decision was made to switch to Kotlin for the Android mobile app development and the server, which only took about a month (with the help of IntelliJ IDEA’s auto-converter). 6 months later, the web version of Down Dog was launched, which was built using KotlinJS.

At this point, code was not being shared between any of the three clients, but they were being written in parallel so that changes to the business logic were essentially a copy-paste job (plus syntax changes when converting to Swift). At the beginning of 2020, Down Dog switched to Kotlin Multiplatform and began sharing code among all three clients for everything but layouts and other platform code. The team has even moved the majority of their iOS platform code from Swift to Kotlin, so that their entire project is now Kotlin with the exception of around 5 Swift files.

Down Dog under the hood

In terms of what is native, it is mostly just the view code. There’s also network interaction, media playback, local storage, and third-party integrations like Facebook login. The rest is Kotlin.

Under the hood, there’s a module structure that looks roughly like this:

Common: multiplatform module containing code shared across the clients and server (mostly various helpers that have been written).

Base: a kotlin-jvm module that depends on ‘common’ and contains non-client code used by the server as well as in standalone tasks.

Server: a kotlin-jvm module that depends on ‘base’ and contains all of the Servlets. This module uses the gretty plugin for running the server locally, and the war plugin for deploying to AWS Tomcat servers.

Tasks: a kotlin-jvm module that depends on ‘base’ and contains various standalone tasks that need to run (database cleanup, generating reports, certain content-specific tasks).

Client: a multiplatform module that depends on ‘common’ and contains nearly all of the code for all three clients. Most of this code is structured as ViewController-View pairs, where the ViewController is platform-independent and the View is an “expect” class implemented separately for each Android, iOS, and JavaScript. This module also contains some “expect” objects which wrap other platform interactions (e.g. a Network object to handle all requests/responses), and it contains data classes representing the API with the server, for which we use kotlinx.serialization to convert to and from JSON.

Android: a kotlin-android module that depends on ‘client’ and contains the Activity class, which calls code in ‘client’ to initialize the app.

JavaScript: a kotlin-js module that depends on ‘client’ and contains a main function that calls code in ‘client’ to initialize the app.

Additionally there is an Xcode project similar to the Android and JavaScript modules, containing primarily just the UIApplicationDelegate class, which calls code in ‘client’ to initialize.

Story of the mobile application

The speed of development for the app was probably the single biggest priority. Launching features simultaneously on all platforms is an important component of this and also helps prevent bugs. Even before we were actually sharing code, we did parallel development and kept the three clients up-to-date with each other. Performance is definitely an important consideration, which makes being able to interact with the platforms directly very important (especially with the media playback API’s).

Having used Java since starting coding in high school, Benjamin had long been a fan of IntelliJ IDEA and had been aware of Kotlin’s popularity among app languages for some time. Discussions between the cofounders ultimately led to the adoption of Kotlin for the project. Much of Java was considered overly verbose and otherwise frustrating for mobile development, and it was often pointed out that the problems they were finding in Java seemed to have been addressed in Kotlin. That eventually led to the decision to try Kotlin, especially because it was also much closer to Swift, which at the time was the only option for iOS. In addition to being able to share code across platforms, Kotlin’s ability to create DSLs was very useful because it is used heavily to write the logic for the workouts. There were never any alternatives that were seriously considered. React Native was the other big option at the time that was being pushed, but there were performance issues (especially on Android), and JavaScript was also unappealing.

Gains from using cross-platform

Now, the speed of development across the three client platforms is pretty much unmatched. A single engineer is able to do all of the UI implementations, now does all three clients and has re-skinned or otherwise changed the screens in Down Dog in just a few months.

If you are putting off using Kotlin for whatever reason, Benjamin has just one last suggestion for you: “Just do it. You won’t look back.”

Visit the Kotlin Multiplatform Mobile portal to find more about cross platform development!

Continue ReadingDown Dog Case Study: Building 500K Subscribers App with KMM

End of content

No more pages to load