Auto Added by WPeMatico
Hello, my name is George Herbert and I am a lead developer currently working as part of the HMRC Mobile App team. HMRC is the UK’s tax, payments, and customs authority. The app helps users to access their Help to Save accounts, manage their tax credits, and review their personal tax situation among other features. The team comprises iOS, Android, and backend developers. We encourage all developers to try other disciplines within the team, which gives us a reasonable level of cross-skilling. My role within the team is being the lead developer of the backend microservices.
About the HMRC App
The HMRC app has been in existence since 2012 and started off as a simple tax calculator. During 2016 the team undertook a rebuild by refining existing functionality, as well as adding the ability for users to login and manage their personal tax affairs, such as their Help to Save account or their tax credits. This means they do not have to ring HMRC or fill in any forms. Currently, we have half a million users a month, with users returning on average 7 times a month. The app is aimed at personal tax users and, when compared to the equivalent web services, it accounts for 50% of total traffic in the personal tax space. One of the app’s most popular and long-standing features is the tax calculator. The calculation logic for this is shared with the web. The web and the mobile calculator combine for 5.7 million visits a year of which the mobile accounts for 2 million of those.
From a Kotlin perspective, the Android team has been working gradually to migrate the app. At the time of writing, 86% of the app is now written in Kotlin
Use of Kotlin Multiplatform
Around 18 months ago my Tech Lead called a meeting to discuss the use of Kotlin Multiplatform (KMP), among other technologies, to help simplify and consolidate business logic within the apps and service. It was agreed that the HMRC Mobile App team, in partnership with Capgemini, would investigate this open-source product as a possibility within the app by starting simple and then going from there.
We wanted the user interface (UI) to be native as this was already built. We also felt building a core for business logic that could be shared, regardless of the choice of UI, would allow us to share this with the web more easily.
As mentioned, one of the main features in the app is the ability to calculate an estimate of your tax and take-home pay based on your salary, payment frequency and tax code. Updating the calculator every year required days of manual testing to ensure that everything worked as expected and had to be done for every platform! We identified this as an area that really needed an overhaul, to help with maintainability adding new tax bands each new tax year and reduce testing effort. The challenge was anything new still needed to support iOS, Android & web.
I am not an Android developer or even a Kotlin developer, my background is a Scala developer. I was keen to learn Kotlin and this seemed like a good opportunity. Within a couple of weeks, the tax-kalculator (see what we did there) was born: a Kotlin multiplatform library, with coverage of 98% and ready for use in the Android and iOS, and even the web version of the tax calculator. Adding new tax years now takes less than an hour and very minimal manual testing, thus saving us days of effort and time.
Over time, we have started to add other multiplatform aspects to the app such as a Help to Save calculator that will help forecast the amount of money you can save as part of the scheme. Going forward we are looking into more sophisticated uses for KMP that would help reduce duplication and improve the user experience across the platforms.
Getting to grips with KMP
As we began using KMP there were a few challenges we worked through as a team. The first was around setting the Gradle to support the platforms, as every example we looked at was slightly different and we were using Gradle.kts which was even more sparse when looking at an example. The issues around limited documentation, or outdated examples, is becomes less of a challenge as the popularity of KMP increases. Furthermore, as part of 1.4.0 the Gradle config has been simplified with the hierarchical project structure making this much easier and straight forward.
We faced a challenge with getting the framework for iOS in a state that could be consumed in our app without directly linking them in the Xcode build. One of the team’s iOS developers found a shell script that we added to our CI, that creates this and exports it to our GitHub. An example of this shell is on the repository for the project called package-ios.sh.
Finally, the iOS team faced the challenge of using multiple KMP projects in the same iOS app. This since been resolved in a newer version of KMP. As for the latter we temporarily (until the fix for this was added in 1.3.70) put all the KMP projects in one “super” library that contained all or KMP functionality just for iOS.
My advice is that if you want to try out KMP start small. For example, just write some business logic which is pure Kotlin and does not need platform-specific implementations, all the code should be in the commonMain. This makes the initial getting to grips with KMP simple as you don’t need to work with the actual and expects keywords. Once you are happy with the projects and their structures etc and they are working in your respective apps look to spread your wings into more challenging KMP (like consolidating your network logic and error handling for example).
I hope this has been interesting. If you have any questions about using KMP or either of our projects that are linked below, please feel free to message me on Twitter (@georgeherby).
HMRC KMP Libraries
Help to Save Kalculator
Something extra whilst your are here…
Recently the HMRC App team has open sourced its UI components for Android and iOS allowing anyone to build accessible apps with the same look and feel as the GOV.UK Design System.
Cash App is the easiest way to send money, spend money, save money, and buy cryptocurrency. We believe in providing everyone with access to important financial services so they can fully participate in the economy. The app launched in 2013 as a simple peer-to-peer payment app with 4 mobile engineers, and it now has 50 mobile engineers (split across iOS and Android) and 30 million monthly active users.
The decision to test out Kotlin Multiplatform started in open source. A library we maintain called SQLDelight was gearing up to generate Kotlin-only APIs, and the decision was made to also use KMM to make those generated APIs platform-agnostic. The fit seemed natural. Since SQLite is the most widely used cross-platform technology around, this would serve as an opportunity to test the technology, and it would open the doors for Cash App to use it later, since the Android version of the app relied heavily on the library at its core.
Visit the Kotlin Multiplatform Mobile portal to find more case studies from different companies!
In the last year, we’ve made major changes to how we use Kotlin Multiplatform to help teams to adopt it. We had originally introduced the Gradle toolchain to the iOS build by keeping the shared code in the same repository, but the added cost of running Gradle and rebuilding the project did not make sense in light of how often the dependency was being changed. Instead, we created a shared repository for Android/iOS to be the home for our shared business logic. Since then, our network, investing, and growth teams have all built features with parts of their business logic in KMM. What has made me most proud is that the contributions have come not only from Android and iOS team members, but from the server team as well! Since we use Kotlin for our server-side development, their team is now able to work in the repository, and because the platform-agnostic Kotlin so closely resembles Swift that the shift is manageable for our iOS team too.
In addition to using SQLDelight, we use CrashKiOS from TouchLab to get better stack traces in the wild, and we are in the process of adopting Wire to work with protocol buffers in the shared codebase. As for which parts of our business logic we’ve encouraged KMM as a solution for, we’ve had the most success so far with persistence and pure functions in the shared code, and next we’re hoping to work more closely with our network APIs using Wire.
Visit the KMM portal to create your first cross-platfrom application with Kotlin!
We love Kotlin Multiplatform because we didn’t have to give up any of the things we love about our work. We’re at a place now where the developer workflow is unchanged but there is an option to share code and get all of those benefits without stepping out of our comfort zone. Our teams are increasingly realizing the potential of KMM, giving it a shot, and seeing how powerful it is.
Senior Kotlin Developer
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!
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.
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).
Android: a kotlin-android module that depends on ‘client’ and contains the Activity class, which calls code in ‘client’ to initialize the app.
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).
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!
Philips is a leading health technology company focused on improving people’s health and well-being, and enabling better outcomes across the health continuum – from healthy living and prevention, to diagnosis, treatment and home care. Philips is pursuing the goal of improving 2.5 billion lives per year by 2030.
Philips has a wide range of connected products for smart home care and personal health that are supported with smart applications for Android and iOS. Typically these products are connected locally via Bluetooth Low Energy or Wi-Fi, and they are also connected to the Philips cloud for remote control or data insights. For these purposes, the Philips Innovation Services organizational unit develops a connectivity platform that comprises embedded hardware, firmware, protocols, and an SDK for creating mobile apps. This connectivity SDK offers components for discovering, connecting to, and interacting with connected products. The SDK targets Android and iOS, with embedded Linux as the native target also becoming more important.
Installed base of mobile apps for Philips’ connected products
The mobile apps for Philips’ connected products have a combined installation count of well over 1 million on the App Store and Google Play. These apps are being installed and used all around the world, with the USA, Europe, and Asia being the biggest markets.
How is Kotlin Multiplatform Mobile used in your product?
One of our SDK components is a client library for Philips’ cloud solution: HealthSuite Digital Platform, or HSDP for short. It enables an app developer to interact easily with the cloud infrastructure without having to write HTTP requests with intricate headers and complex payloads. Instead, developers can call high-level functions, such as
to download a binary file,
to control a cloud-connected device remotely, or
to upload telemetry data.
Visit the Kotlin Multiplatform Mobile portal to create your first cross-platfrom application with Kotlin!
Boilerplate code generation with Kotlin
All HSDP service endpoints are documented in the OpenAPI (Swagger) YAML format. Using these definitions, we generate a lot of boilerplate code during a build, which allows us to be ‘in sync’ with the cloud services in production. Our team has created the Kotlin codegen module for the popular OpenAPI Generator, which we are contributing to on Github. The code we generate with this includes all the necessary data transfer objects and classes that wrap the HTTP request/response handling using ktor. This means that we can focus on writing the business logic that builds on top of the generated code, instead of spending extra time working on the plumbing. The moment a production service is upgraded to a new version, we re-generate the code for it using the updated
file and we can immediately spot the changes we need to make.
Designing an API for Java, Swift, and Kotlin
An interesting aspect of writing a Kotlin Multiplatform SDK component is thinking about your API. Each platform language has its own paradigms. For instance, asynchronous operations are handled slightly differently in each case. In Java it is natural to invoke an asynchronous method with a callback argument to handle the result, for example:
In Swift, we are used to using completion handlers in this type of scenario. For example:
And finally, for Kotlin users we’d like to offer an API with the suspend keyword, so they can make use of it using coroutines. One problem that quickly arose with this was that defining multiple method signatures on the API would generate more than is needed on each platform. Suspending functions are for instance converted for Java, but especially on Android SDK levels below 24 (which don’t have support for all Java 8 language features), the result generates quite a verbose signature that is hard to work with. To address this situation for all target languages, we added functions with specialized signatures for Java, Kotlin, and Swift on the external API. These signatures wrap the
variant using a custom
wrapper function that arranges the correct
for executing suspending functions. The
annotation was key in hiding the incompatible Java variants.
This enables us to offer the API function signatures that feel most natural on each native platform while keeping the business logic concentrated under one implementation.
Why did your team decide to use Kotlin Multiplatform?
We had been busy building SDK components for Android and iOS for a while, and cross-platform code reuse was not really happening apart from a few bits and pieces in C, such as the implementation of the SSDP protocol. However, because of the difficulty of bridging between Java, Objective-C, and C, we actually ended up reimplementing this protocol natively on each platform.
This meant that the development team was also split in two when we were implementing new features. The advent of Kotlin Multiplatform provided a serious opportunity to not only become faster at implementing new features, but also to get more interaction in the team between Android and iOS developers.
We knew that Kotlin Multiplatform would still evolve a lot, but the benefits of being able to write once, test once, and deploy more as a res
ult, were compelling enough.
Some of the things that we learned from this experience were:
The integration of the Kotlin Multiplatform plugin in the IDE (IntelliJ IDEA/Android Studio) has not always been ideal, but it has definitely improved with each release.
There is always a trade-off between code reuse and writing stuff natively, but this holds true for every cross-platform solution. You have to think hard about which types of business logic can be converged and which should remain native.
Adopting Kotlin/Native on iOS is definitely harder than using it on Android or JVM, especially when it comes to IDE and debugging support.
With Kotlin Multiplatform, our development team is able to push out new features much faster, the codebase is easier to maintain
The Kotlin language itself helps us write better code with less effort.
We have seen an increase in interaction and knowledge sharing between the Android and iOS developers in the team.
Leaving the ecosystem to the community allows JetBrains to focus on the essentials and move faster.
We are planning to target Linux natively as well, so we will have lots of opportunities to see whether the shared codebase pays off. For anyone thinking about using Kotlin Multiplatform, my suggestion would be to look at that portion of your codebase which does not directly interact with platform-native APIs or interfaces that are specific to one platform. Focus on the business logic that has a clear overlap between platforms, since that is where you can actually gain the most.
Jeroen Brosens, Mobile Connectivity Architect, Philips Innovation Services
Visit the Kotlin Multiplatform Mobile portal to find more about cross platform development!
The Kotlin team has always relied on feedback from the community for making decisions about the future of the technology. You will always be our go-to people who know best how to make Kotlin even more enjoyable to work with!
This past November, we conducted our first-ever Kotlin Multiplatform survey with the goal of understanding how the recent changes in the technology have shaped the ways developers use it. This initiative was well received by the community, resulting in an astonishing 1163 replies and 614 fully filled-out surveys, which are the basis for this report. We want to say thank you to everyone who took the time to share their feedback with us.
As a result of this survey, we were able to get a much more complete understanding of our users, how the technology is generally used, and what problems need to be solved to help those using Kotlin Multiplatform for work, personal, or university projects and those who are thinking about adopting Kotlin Multiplatform.
This is the first report of its kind and it will help shed light on the current state of Kotlin Multiplatform. We will also share our thoughts and conclusions about what is going on with the technology and reveal some of our plans for future changes and improvements that will be done in response to the present state.
Developers with an Android background prevail among those who use Kotlin Multiplatform. But the number of developers with backend experience is big too. Surprisingly, as many as 8% of the respondents are from an iOS background.
We are very happy that Android developers enhance their knowledge and skills with the capabilities of Kotlin Multiplatform, which helps them go beyond Android development. It is also nice to see that the technology is attracting such a wide variety of users from different backgrounds and that it provides everyone with so many opportunities.
With 61.4% of the respondents having more than 5 years of development experience, we can conclude that Kotlin Multiplatform is interesting to those who have a lot of knowledge in programming. It is an honor for us to be chosen by developers with so much experience. But if you are still a middle or junior level developer, please do not worry — making Kotlin Multiplatform friendlier for everyone is our top priority and we will take steps toward helping less experienced developers get started with Kotlin Multiplatform too.
How Kotlin Multiplatform is used
42.2% of the respondents use Kotlin Multiplatform for sharing code between iOS and Android. This means they are using KMM, which recently branched into a separate project and went Alpha with big investments from the Kotlin team. Mobile targets + WebClient conjunction and backend + WebClient are popular too, but what is most unexpected is that the technology is being used by 16.3% for all existing targets that are aiming to have their code as universal as possible. One example of the all-targets approach is Space by JetBrains, which has recently been released and is built almost entirely on Kotlin.
Kotlin Multiplatform is a popular choice for creating open-source libraries and internal SDKs, but we are very excited to see that the technology is trusted by 41.1% of respondents to build user-facing applications with shared code or at least parts of them. It means that sharing code with Kotlin not only helps many developers save time and effort with a consistent and fast development process, but also satisfies the needs of their users.
“Is Kotlin Multiplatform ready for production?” That is one of the questions we are most frequently asked. According to the survey results, more than 56% of the respondents have already released an application with a shared module or are about to release one in the near future. This means that even though the technology is still in Alpha, it is trusted for use in production and it is already giving many companies and independent developers around the world the benefits of reusing code between platforms.
Data serialization and algorithms are the most popular parts to share between mobile platforms, with internal utilities, data storage, algorithms, and data synchronization just slightly behind. You can find more information about particular companies and their use cases in the case study section of the Kotlin Multiplatform Mobile developer portal.
KMM was designed to help developers reuse their business logic between mobile platforms and still keep the native UI. It is great to see that the original purpose is not stopping developers and KMM is being used for multiple different purposes, from reusing networking logic to sharing the UI.
Check out our step-by-step guide on how to create your first application with a shared codebase.
Nothing is perfect and Kotlin Multiplatform is no exception. The strict Kotlin/Native memory model, build setup, problems with libraries, and IDE support tend to bother our users the most. It is good to be on the same wavelength because all of the pain points that are being highlighted are already being included in our roadmap. We hear you and we will try to do something about these issues to make Kotlin Multiplatform as easy and fun to work with as possible.
More than half of the respondents use Android Studio to unleash the capabilities of Kotlin Multiplatform. IntelliJ IDEA Ultimate and IntelliJ IDEA Community Edition are the next most used tools with 27.3% and 16.7% respectively. The only way we can improve the developer experience with the IDEs is by creating better tools, but in order to do so, we need more feedback and usage data. We encourage you to help us and enable statistics sharing with JetBrains (if you use IntelliJ IDEA) and Google (if you use Android Studio).
52.6% of our respondents would like to use CocoaPods for exporting Kotlin Multiplatform framework to the iOS app. We are very happy with the amount of feedback we have had about this technology, and we have some great ideas on how we can improve the developer experience of working with it.
We were surprised to discover that 25% are interested in having Swift Package Manager integration. We will pay more attention to this in the future and will reconsider our backlog in order to take further actions to satisfy the needs of our users.
Onboarding and documentation
We were very interested to find out how developers approached their first Kotlin Multiplatform project. The results show that creating a project with the IDE wizard, using the official step-by-step guides, and cloning the official samples are the most popular ways for developers to start exploring the technology. It is good to know that in order to get started, developers use the KMM portal and the official documentation, but they don’t forget about resources that the community creates and maintains around the world either, as these also provide a great understanding of how to start benefiting from sharing code between platforms.
Improving the experience developers have with Kotlin Multiplatform is our top priority. In order to increase the level of satisfaction with Kotlin Multiplatform, we need to continue to improve and maintain the documentation. From the answers we received, we see that we are lacking particular use-case samples, ready-for-production examples, and articles the most. To cope with this challenge, we have created a documentation improvement backlog that will reduce the lack of these types of content about Kotlin Multiplatform. The focus will first be on common user scenarios that are not well covered in documentation articles, such as testing, and then on creating hands-on tutorials and samples for building apps from scratch and also for apps that have an integrated multiplatform module.
With all the feedback that has been gathered through the first Kotlin Multiplatform User survey, we understand that we are on the right track. The technology is evolving fast and it is already helping many companies and independent developers share code between platforms while they create user-facing applications.
We are very happy that the community has welcomed our attempt to understand how developers use Kotlin Multiplatform and we had more than a thousand replies. This information provided us with many insights and helped us reconsider the fields that had previously not been so clear. We plan to organize this activity on a regular basis and conduct a Kotlin Multiplatform User survey around twice a year.
Once again we would like to say a huge thank you to everyone who participated in this survey! We believe that together we can make Kotlin Multiplatform the best technology to work with.