7 ways to convince your engineering manager to pilot Kotlin Multiplatform

We hear similar stories when we speak to mobile developers interested in a Kotlin Multiplatform pilot for their team. The story goes something like:

You’re a developer. You’ve seen the growing momentum that Kotlin Multiplatform (KMP) is gaining in the developer community – especially since Google announced it was officially supporting Kotlin as a development language in 2017.  And now you want to try it for yourself. (Or maybe you already have.) More important, you’d like to try it on a live project, with your colleagues at your workplace.

The question is, how do you convince your manager that it’s a viable framework to use? They already have enough to deal with, right? Hard deadlines, pressure to produce faster, test more thoroughly, improve architecture, deal with tech debt… the to-do’s for them go on and on and on.

If you’re convinced (like we are) that Kotlin Multiplatform is the best option for unified development of business logic across iOS and Android – but are not sure how to broach the subject with your manager — we’ve put together seven key talking points for you.

1. “One code base. One team.”

Using Kotlin Multiplatform, we can code business logic across both platforms. That means the team doesn’t have to do the same work twice — once for iOS and once for Android. No duplication. Saves time. Saves money. (And saves a lot of nerves, too.)

2. “Kotlin itself is skyrocketing.”

More development teams are using it, and more individual developers want to use it, whether they’re Android or iOS. It doubled in popularity each year since 2015, and after the Google announcement in 2017, it went stratospheric. It’s especially popular among programmers looking to grow their careers. 

3. “KMP plays nicely with both iOS and Android.”

One way to think about it: Lexus has the same engine as a Toyota — the only thing that’s different is the exterior. Same with iOS and Android. They’re essentially the same under the UI hood, so it’s very straightforward to deploy to either platform with few if any hiccups. 

4. “Using KMP is low-risk.”

It’s not an all-or-nothing proposition. We can do the programming incrementally, one feature or architectural layer at a time, so there’s no disruption to hard deadlines. It’s not a major commitment to pilot a project.”

5. Our team can focus on innovation as well as  production.

If we’re only writing the code once for both platforms, it gives us the potential to focus on fine-tuning the architecture, designing more features, or exploring other innovations because we’re not bogged down in production only. Focus on new stuff or focus on testing. Frees up resources to do more stuff…

6. “Keeping UI separate is a good thing. It ultimately will save us time.”

KMP doesn’t do UI at all, but that’s actually a real advantage for us. Sharing UI across platforms can be risky because it involves doing multiple reworks and workarounds to make the UI work natively on its respective platform. With KMP, we can focus on the business logic specifically, and leave the UI to be coded separately.

7.     “With KMP, we’re future-proofing our business logic.”

KMP doesn’t lock into one ecosystem like Flutter or React Native or Xamarin. It’s easy to take an Android library and make it work as a KMP library – even easier if the library is already written in Kotlin. And of course, Google’s endorsement of Kotlin is a big plus.