Sharing business logic between Android and iOS with Kotlin Multiplatform

If a customer also wants their business to be present and successful on the Android and iOS mobile platforms, there is often no alternative to using a mobile app. The needs of the user on a smartphone can be taken into account better with an app than solely with a homepage. Native platform features such as push notifications or the smooth integration of Google Pay or Apple Pay can significantly enhance user experience and also have an impact on customer loyalty and the success of an app. Today, users of the respective platforms have high expectations of the user interface. This also helps them to quickly find their way around a new app. This includes, among other things, correct navigation within the app, as well as compliance with the UI guidelines of the respective platform. An Android app created with iOS guidelines is usually weak.

Native apps are the measure of things

The consumer often requires a sophisticated design with animations and the use of the latest platform features (for example, Dark Mode) – preferably from the day on which the new OS version was released. Given these requirements, there is often no way to avoid a native app. Native OS features such as access to the fingerprint reader or the Bluetooth interface can also be used with other cross-platform solutions, however, an external plugin is usually required. This does not originate from Google or Apple itself and may contain potential errors.

Even Apple and Google are not immune to bugs. However, due to their high volume of testing and large user base, these bugs are spotted quickly and are eliminated swiftly. When it comes to third party plugins, on the other hand, the question is whether possible errors are (promptly) fixed. Against the background of these uncertainties, it is difficult to start a challenging project as a major or even unsolvable problem could arise in the middle of the development process. Although just using the Bluetooth interface is in part no small task, even in native development, thanks to the large community and vast experience in native development, a lot of help is available on the Internet.

Cross-platform solutions are still very new and are not widely used. This could result in there being no solution to a problem.

We’re staying in the native world

The Kotlin Multiplatform makes it possible to just share the code of the business logic and stick to the respective native world with the rest. On both platforms, the shared code is maintained as a library. This allows developers to continue to use their familiar tools and languages. Furthermore, the native OS features can still be accessed. If something changes in the business logic, the developers only need to update the library. It is also possible to gradually migrate the business logic to a shared library.

This means that the UI and UX remain completely under the control of the native platform and its developers, who have years of experience and can handle it efficiently. When new platform features, such as Dark Mode, are introduced, all that is needed is an update of the UI without affecting the business logic. Even with larger platform updates, such as a new way to develop the UI (SwiftUI/Jetpack Compose), there are no obstacles to using this.

A problem shared is a problem halved

By sharing the business logic, it only needs to be developed once. We are familiar with the promise of ‘Developed once – runs on both platforms’. Unfortunately, this promise was compromised in the past. Particularly in the case of the UI, time-consuming UI/UX adaptations were required time and again for one of the platforms.

When business logic is shared, the focus is placed only on the business logic and correct implementation. It is therefore possible to ensure that the logic will run properly on both platforms after being implemented correctly once. Especially when developing an Android and iOS app, it is more common to encounter different errors in the apps, as the developers may have understood the requirements differently or implemented them incorrectly.

The business logic to be shared between the platforms is developed – with two exceptions – just like a normal Kotlin library. The exceptions are found when configuring the project and when using native Android or iOS features in the shared code. When configuring, it is necessary to define which platforms to support. In our case, this would be Android and iOS. A lot of documentation and help on configuration is available on the official Kotlin Multiplatform project page. It is usually only necessary to configure once at the beginning of the project.

When using native platform features such as log output on Android (with the help of Logcat) and on iOS (with the help of NSLog), the two specially added keywords expect and actual play a major role. This makes it possible, as in the case of an interface, to define method signatures that in turn need to be implemented natively. This means that platform-specific differences can also be implemented in the shared logic. This is relevant for biometric sensors and GPS functions, for example, as there are greater differences between the platforms here.

Under the hood

When using the library on Android there is the option to create an Android Archive (AAR) that can be integrated into an Android project like a normal dependency. Alternatively, the code can be integrated into an Android project as Git submodules. Both have their advantages and disadvantages.

To use the library in an iOS project, the code is compiled into a framework using LLVM. This allows the resulting framework to be used in Objective-C and Swift projects, just as other frameworks are integrated into a project.

It’s all about the money

When a customer opts for a classic cross-platform solution when planning an app, they usually have the potential cost savings in mind. There are very good arguments for this. However, the critical points often go unmentioned and heaven and earth are promised: ‘One person develops one app for both platforms in the shortest possible time’. This may be true for smaller apps at best, but the initial cost savings turn into a financial drain, particularly in the case of larger projects.

If the app is to look good on both platforms, with nice animations and smooth transitions between the individual screens, things will get complicated very quickly when using common cross-platform solutions. The developers need a great deal of knowledge of the respective platform in order to be able to implement these requirements. This requires them to be familiar with the cross-platform solution as well as the two native platforms. With this alone, the developer needs to have an in-depth understanding of three platforms and must also keep this knowledge up-to-date.

A new major software update is released every year for Android and iOS and often offers many new features.

But even when it comes to cross-platform solutions, the world turns no slower than in the native world. New solutions come and go and the more time passes, the more difficult it becomes to find developers for them, as the developers may have already moved on to a new venture. This problem does not exist in native development. A native developer can get along with older and newer apps and is often an expert on their specific platform. Not only can they implement the requirements; they can also advise the company in order to get the most out of the platform.

Sharing is caring

We believe there is no alternative to the Kotlin Multiplatform. The focus on sharing business logic is a clear advantage for us over other cross-platform solutions and silo development (Android and iOS are developed separately without sharing code or anything similar). The Android and iOS developers really enjoy using the Kotlin Multiplatform, as they hardly have to adapt their usual way of working. They can also continue to use their knowledge of the respective platform in order to develop great apps with smooth animations, beautiful transitions and satisfied users.

Would you like to learn more about exciting topics from the adesso world? Then take a look at our blog posts that have appeared so far.