This probably isn’t the first article you’ve read about cross-platform mobile app development. It might not even be your first article trying to look at pros and cons of using Kotlin Multiplatform for app development. If you’re like us, you recognize that there must be a way to share code between iOS and Android while respecting the unique environment and user experience of each.
October 5, 2020
Kotlin Multiplatform Pros and Cons for App Development
Our Trial Project
At FreshWorks Studio, we recently created “The Deals App” for the BC Federation of Students, and we did it using Kotlin/Multiplatform (KMP) for iOS and Android. At the time of writing, we’ve been maintaining the app for roughly 1 year, and we’ve experienced a lot of the pros and cons to using this new, experimental technology by JetBrains. We adopted KMP for the Deals app since we believe in sharing business logic, and in how it solves the disadvantages of other cross-platform solutions. We wanted to be an early adopter of a technology that we anticipate will revolutionize mobile app development.
Why Kotlin Multiplatform?
Before starting development on The Deals App, we had been researching Kotlin Multiplatform pros and cons while studying their documentation. We believed in the KMP approach: to share logic without mandating an entire architecture. We hoped that sharing logical components between mobile apps would reduce the development time, improve the quality of the code, and have no impact on performance.
In the past, we’ve examined the cost and benefit of native vs hybrid applications. We had investigated several other cross-platform technologies, like React/Native and Flutter, but we didn’t like how those technologies made the UI identical for both platforms, and we were intimidated by the all-in commitment they required. Our Android and iOS teams agreed that for performance’s sake, the UI should be native to the OS.
When The Deals App came along, it looked like the perfect fit for Kotlin Multiplatform. It had a shorter development schedule (we didn’t want to get locked-in on a huge app), and it had few OS-dependent features like BLE and push notifications, which, although possible to develop with KM, yield diminished benefits. Our developers are also cross-functional and have an understanding of how the other platform works. This helped a lot in coming up with an architecture for the app.
Kotlin Multiplatform Pros:
How It Helped Us
As our team adapted to a modified development cycle, our feature delivery accelerated. For a new feature, one developer (e.g., an iOS developer) would add model objects, networking, business logic, and unit tests to the multiplatform module. Then the other (e.g. an Android developer) would just plug the feature in. This helped us cut the development time exponentially as we were developing features.
Improved Code Quality
Sharing a codebase had some unexpected positive outcomes. For one, our iOS and Android developers talked to each other a lot more. Better communication led to finding more corner cases and logical errors early in (or before) development. It also led to greater functional consistency between the apps. Another benefit was the inherent modularity and testability of the multiplatform code we wrote.
Since the Android and iOS applications effectively use the same piece of code for the business logic, it was easier and faster to test and add new features. We were able to onboard new developers as well without the need for extensive knowledge transfer. A new developer coming in was able to understand what was going on with the project because of all the modular and testable code.
Kotlin Multiplatform Cons:
Complications to Consider
Relative to the more familiar native iOS or Android which we have used for dozens of apps in the last few years, Kotlin Multiplatform presented us with a unique set of hurdles to overcome. Here are a few worth mentioning.
Longer Project Setup
Since it was our first trial, the project initialization took us longer than expected. We had to do a lot of brainstorming to settle on approaches for the application architecture, Git repository management, Jira tickets, CI/CD, etc. We came up with several approaches before finally finding the one that worked well for us.
Requires a Cross-Functional Team
Kotlin/Multiplatform worked well for us because our iOS development team is enthusiastic about learning Kotlin. If this were not the case, the development of almost all of the common code would have fallen on the Android developers and left iOS developers waiting for the business logic to be ready. The cross-functionality of our developers paved the way for multiplatform development.
Tricky iOS Debugging
Kotlin/Multiplatform’s debugging support on iOS leaves a lot to be desired. In particular, the error logs were usually generic and unclear. Sometimes, this slowed us down measurably.
Is Kotlin Multiplatform Right For You?
Our development team loved working with Kotlin/Multiplatform for The Deals App and would highly recommend it for developing cross-platform solutions. However it is important to understand that it’s not a “one size fits all” situation with mobile development.
A lot of factors affect the decision on which method to use for developing mobile apps. It’s important to consider the complexity of the application, and its reliance on OS-dependent features. In many cases, it may be better to develop natively. For this project, our expertise with mobile development and understanding of the nuances of Kotlin Multiplatform helped us to write robust, well-tested code.
0 Crashes To Date
According this Crittercism Report (which is in line with my own experience) 47% of mobile apps crash more than 1% of the time.
For the Deals apps, we have been very happy with the results. Our apps have been live on the Google Play Store and Apple’s App Store since September 2019, with thousands of users and no reported crashes yet.
Written by Skyler Smith | Oct 5
Kotlin Multiplatform Pros and Cons for App Development
Written by Desmond Brisbin | Oct 2
Diversity & Inclusion is Key for Growing Companies
Written by Shannon Parker | Sep 23