For the first in our Native Mobile Leadership Forum series of events, we spoke to three market-leading companies about their use of Kotlin Multiplatform.
What is Kotlin Multiplatform?
Over the past few years Kotlin has been steadily growing in popularity, with 5.2 million people having edited Kotlin code in the past 12 months alone (a growth of 150% from 2019). Although the majority of code is currently written for Android and JVM frameworks, use of Native and JS code is growing rapidly as KMP expands.
Karhoois a white label Mobility as a Service (MaaS) platform provider that connects businesses to taxi fleets around the world, allowing them to deliver branded e-hailing solutions to their consumers directly from their branded website or app. Learn more about their products and services on the Karhoo website.
What attracted Karhoo to Kotlin Multiplatform?
About a year ago, in a period of high growth, Karhoo found that it was becoming more arduous to coordinate and align feature development across their mobile and web clients. With concerns around feature parity and API coherence, the Mobile Engineering team started investigating KMP as a means of working more productively and efficiently by adopting a single codebase for common business logic.
Karhoo decided to evaluate KMP as a future option by building a single implementation of low-level, networking software and common business logic with the framework. Using code generation, the corresponding clients for Android, iOS and Web were created in an attempt to reprise that old engineering dream of ‘write once, run everywhere’ software.
Working with Kotlin Multiplatform
As is to be expected when introducing any new language or framework that involves changing working practices, there was some internal resistance, however this was heavily outweighed by the potential long-term benefits that KMP had to offer.
Karhoo knew they didn’t want a full-stack application solution – frameworks such as React Native, Xamarin or Flutter would involve a full refactor of most of their codebase, something which would be impossible at this stage. So, with buy-in from the principal engineers, the project began in earnest.
Despite not being able to reliably combine Android, iOS and Web code efficiently to begin with, the new release of Kotlin 1.4 which included an IR compiler allowed for greater stability and ease of integration. Karhoo began conversations with JetBrains, the company behind Kotlin, and soon established a strong relationship with their multi-platform teams across all domains.
According to Sean Keane, Principal Engineer at Karhoo at the time,
“These guys are committed to making KMP work. They've worked really hard to make it work for us, the community itself is really nice, and they're consistently pushing products. We felt like anytime there was an issue, we weren't left waiting for weeks trying to get an answer on it. They were working closer with us each time we were getting closer to answers, and that was feeding back into the product.”
Results and final thoughts
Karhoo started by building a product called Karhoo Core, a foundational core networking stack that enabled the client teams to unify their APIs for Android, iOS and Web by providing a unified SDK that they could build on top of. By keeping the core libraries native, Karhoo could ensure optimal compatibility and accessibility for all partners, regardless of any new updates.
And for customers concerned about a lack of support for the libraries they want to use, or wanting to implement something new, JetBrains revealed another great KMP feature. As Sean put it:
“The guys have you covered in KMP with a mechanism called expect/actual, which means you can wrap up your favourite libraries and use them through a common interface and common code. So, you can take some of your favourite libraries or even tweak and tune them yourself, mix and match them and produce an SDK with them on the platform that you're targeting.”
Karhoo did have some caveats to promoting KMP, however. The fact that the initial web package was still quite large at the time was seen as a deterrent to some parties, however following compression from the new compiler this can be reduced considerably to mirror the size of other web frameworks like React. Their second point was about the initial switch to KMP, and how important it is to get the right buy-in and support. In Sean’s view:
“A lot of engineers have the fear of the unknown – they know their platform, they know they're comfortable in their platform, that doesn't necessarily mean that they want to move. But if they can see the actual advantage of speeding up their delivery and overall feature throughput, that's where it becomes very important. With the support of JetBrains and my background knowledge in KMP, I was able to set up my own company.”
Skalable, the company in question, is a developer experience consultancy that provides the required skills and training you need to help your development teams develop rapidly and productively with Kotlin as the heartbeat. Skalable uses the power of KMP to assist your engineering requirements across all platforms including iOS, Android, Web and back end, and pride themselves on helping you keep your codebase maintainable, flexible, and of course, ‘skalable’!
Learn more about Skalable here.
A joint venture between Blenheim Chalcot and the British Council, EnglishScore is the world’s only mobile-proctored English test, assessing people’s English language ability and offering an optional certificate for official use. To date, over 1 million tests have been taken through the company, and it has been hailed as a much more efficient and accessible means of testing than the current system of queuing and paying upfront to sit a physical test with no guarantee of passing.
What attracted EnglishScore to Kotlin Multiplatform?
As EnglishScore were starting fresh with no existing stack or legacy, the first decision was whether to opt for native or non-native. Seeing as the company had one core product and sharing across platforms had proved difficult in the past, they initially opted for a native solution, but when an Android engineer suggested KMP, Head of Engineering Matthew Magee had to consider the benefits:
“I get to keep all the lovely stuff I like about Native, but just hive off that business logic and potentially the network layer – I get all the benefits and a little bit of scalability. So while there was no business imperative to go to KMP, efficiency and scale are a pretty easy sell. And actually, I was sold. That made it easier for me to sell native development to my CTO, because we were actually technically going to be sharing some of this code. So the business logic came together and made a lot of sense. Everyone got what they wanted, I got fully native apps, the business saved some money on development, and the team got to work with exciting new technologies.”
Working with Kotlin Multiplatform
When first setting up infrastructure across the platforms in 2019, the team did come across some stumbling blocks. Updates took a couple of days to sync, things weren’t working out of the box, and this was primarily due to most dependencies like Gradle being in alpha and beta. However, after returning to the project in 2020 when 1.4 was released, Kotlin had made major updates and the process was much smoother – most of the critical dependencies moved in the core framework so they only needed to depend on one main library. Also, the community and documentation had grown enormously, meaning there was much more resource for learning.
Results and final thoughts
The app has now been live for 18 months with, with 99.8% uptime over the past 6 months. EnglishScore have found that most core dependencies are managed well by JetBrains, and there are no pressures from shared dependencies, resulting in much cleaner architecture. Plans for the iOS app are in place, and it is due to be released soon.
As Mobile Engineer Dragos Sassu summarised:
“It still involves effort, it still involves someone looking at the setup documentation, reading and understanding what's happening there. But I think the point here is that you have it – the documentation is there and it’s reliable. You can understand most of the problems that you will face for a production environment, and I’ve never had an issue so far where I couldn't understand what I need to do next in order to solve a problem.
“If you understand how Kotlin works, you will be able to solve over 80% of the problems that you will face in KMP. Sometimes it's just about understanding software engineer principles, architectural decisions, protocols, reactive programming, blocking and unblocking code, and then trying to understand how Kotlin tries to address the specific issue.”
Future Platforms is an agency which specialises in designing and engineering mission-critical digital products for ambitious brands, providing end-to-end services which cover all aspects of the digital journey, from conception to design to delivery.
What attracted Future Platforms to Kotlin Multiplatform?
As many of Future Platforms’ apps had feature parity within their functionality, they were looking for UX that was in keeping with the native feel of the platform, but had identical features and behaviours across iOS and Android in order to streamline processes, increase collaboration and reducing overall code.
In 2018, the company was starting a new project for a room booking management company which would stretch across multiple platforms, and decided it was time to break from their native approach and find a simpler solution. At this time, Kotlin was growing in popularity, and generally considered a “breath of fresh air” compared to Java, the traditional language for Android development, which many developers were no longer interested in using.
Working with Kotlin Multiplatform
Future Platforms’ mantra for development is to keep layers thin, having as little native business logic as possible. Through KMP, they could ensure that everything above that layer is shared in Kotlin in the form of an MVP architecture. In the classic model, multiple teams work separately on their own fully native implementations, but despite some collaboration between teams, the scope for this is heavily reduced without a shared code base. The teams used to find subtle deviations in functionality, not to mention the additional time that's spent on creating these code bases twice over.
With the KMP approach however, there’s been a huge amount of code sharing, with only one pass required on development and bug fixing. Unit testing can easily be achieved because the shared code isn't talking to any native services or framework codes that are difficult to mock, and this is all down to the elegance of Kotlin.
Results and final thoughts
“I think some of you sometimes when you're looking at an approach like this, you may be concerned that you're going off piste, and you're doing something that's not quite vanilla.”
Fortunately for Future Platforms, the JetBrains community support was extremely useful and of high importance to their project’s success, especially as the team were working with uncommon dependents. They also benefited from Klock, Kotlin’s date and time library.
Overall, KMP was a low-risk solution for the company which provided rapid evolution as the framework is always evolving, the only downside being that dependencies can sometimes go out of date and the business impact of this is often not anticipatable. Similarly, project setup is now much easier, but if you’re not completely vanilla, things may require some tweaking while Kotlin work to develop further.
Finally, one of the biggest benefits of KMP that Future Platforms found was the collaboration between teams. As Douglas Hoskins, Head of Mobile, noted:
“KMP uses standard tools, so developers get to use the tools that they know and are familiar with, and it's easier to find those developers as well as building a team. You need to come up with shared code that works for both iOS and Android, so your teams are really going to be working together to define that, and you're going to be getting more eyeballs on your shield code. Android developers will usually take the lead initially, but iOS devs need to bring an open mind and get ready to kind of roll up their sleeves.”
Thank you to all our speakers from Karhoo, EnglishScore and Future Platforms for taking the time to tell us about their experiences with Kotlin Multiplatform. If you’d like to learn more about future Native Mobile Leadership Forum events or are interested in our mobile developer recruitment capability, please contact our specialist Jacob Brown directly on 07923206342 or email email@example.com.