Our Journey to Kotlin Multiplatform at fulfillmenttools
fulfillmenttools relies on various mobile applications, each of which has been developed for specific scopes. In addition to our highly efficient order routing, part of our Distributed Order Management System (DOMS), our platform offers comprehensive Order Fulfillment solutions. Our Operations App, a native Android application, was the first application we developed. It supports central processes in stores and warehouses, such as picking, packing, creating shipping labels and handover to various shipping service providers.
Of course, market requirements are not just limited to Android solutions. In specific cases in particular, availability on iOS and as a web application is also expected. In order to efficiently meet these requirements, we developed a web application based on IONIC. The available resources allowed us to implement it quickly, so that the IONIC web application now offers the same feature set as our native Android app.
However, this parallel approach is not ideal: limited resources such as time and manpower are used twice to implement the functions in both applications. We therefore set out to find a more efficient and future-proof solution and found it in Kotlin Multiplatform.
Why Kotlin Multiplatform?
When evaluating potential frameworks for a cross-platform application, we analyzed several options, including IONIC, Flutter and Kotlin Multiplatform. As we already had experience with IONIC, we were able to assess its advantages and weaknesses. However, despite the familiarity, there are some limitations, especially regarding the publishing process in the Apple Store, so IONIC is not an optimal solution for us.
We carried out a proof of concept (POC) for Flutter. However, we quickly realized that this framework did not meet our requirements either. The learning curve for our Android developers would be very steep. It is also difficult to find experienced Flutter developers on the market.
Kotlin Multiplatform ultimately convinced us with several decisive advantages: Our Android developers can continue to work in their familiar environment without having to change the development environment or programming language. Although there is a learning curve, it is much flatter than with Flutter. At the same time, Kotlin Multiplatform offers the option of developing fully native applications for the target systems. Another advantage is that it is easily expanded to additional platforms in the future. If there are requirements that cannot be implemented directly with Kotlin Multiplatform, it is possible to switch to the respective native language and thus address specific sensors directly, for example.
Despite the still young maturity of Kotlin Multiplatform, supporters such as JetBrains and Google give us confidence that this technology will continue to exist and be continuously developed in the long term.
The challenge of converting to Kotlin Multiplatform
The decision for Kotlin Multiplatform (KMP) has been made - now the challenge is to implement the changeover as efficiently as possible. Our first idea was to develop a completely new KMP application for Android and iOS in parallel to the existing native Android app. We have already tested and gone live with the development of a new KMP app for our returns process. The returns app is available in the mobile stores and is actively used by our customers. The entire returns process can be completed intuitively by the customer within this application and imported into our system. This means that the returns process is also supported on mobile devices and seamlessly integrated into our system.
However, there would be some disadvantages when proceeding further, for example when migrating the picking module from the native Android app to the KMP app: Firstly, we would have to maintain the picking module (and all others) for the old native app and the new KMP app in parallel as long as both apps are actively used. Secondly, it would be necessary for our customers to switch completely from the native app to the KMP app at some point - an additional expense that we would like to spare our customers.
We have therefore decided to convert the existing native Android project into a KMP project. Step by step, we can now migrate the Android modules and integrate them into the KMP environment. As soon as a module has been migrated, it can be used for Android and iOS. We take advantage of the fact that KMP supports the seamless integration of native Android code for the KMP Android application. This allows us to compile a KMP Android application that integrates the existing native code and at the same time uses already migrated KMP modules such as picking. However, the iOS KMP application will then only access the modules that have already been migrated.
Conclusion: The path to Kotlin Multiplatform
At fulfillmenttools, we rely on Kotlin Multiplatform to efficiently meet our customers' cross-platform requirements. After evaluating alternatives such as IONIC and Flutter, KMP ultimately convinced us with its ease of use, very good results in the resulting applications and the effective use of existing resources. Instead of a new development, the existing Android app is gradually migrated to KMP, which avoids parallel maintenance work. KMP therefore offers a flexible, future-proof basis that is also supported by major players such as Google and JetBrains.
Going down this path has cost us some resources, but we believe that it was the right decision and that it will enable us to bring even more effective applications to the market.?