Hey everyone, I’m exploring incorporating KMM into...

# multiplatform

[Martina Rauert]

Hey everyone, I’m exploring incorporating KMM into our existing and established native iOS and Android apps. I’ve got a proof of concept working, so I know technically KMM will work. I’m just not sure if it’s the most practical.

What I’m wondering is: from a broad, anecdotal perspective, does anyone have any experience/advice where the addition of KMM will alter the existing development process? What lead you to decide to adopt KMM or not?

[Martina Rauert]

Specifically, in our native Android app, we currently leverage language features/libraries that require the JVM, so we cannot port these features over directly to a KMM/Kotlin standalone implementation. Specifically:
• We leverage the annotations and class reflection language features that are not available in Kotlin
◦ And subsequently, a dependency injection library that relies on these language features
• Would need to replace the API Client library we currently use with KTOR
• Mocking was not possible in the iOS env since the well known/supported libraries require JVM (MocKMP supposedly works but I personally was not successful).
While none of these are insurmountable problems, they do disrupt our current design and development process - especially the first point.

At the end of the day, I know we’ll have to decide for ourselves what tradeoffs we want to make. But I am curious what everyone else’s experience is, and at what point you all decided to (or not) adopt KMM into your existing native apps and how you overcame these types of obstacles?

[egor]

there are all depends on team/team size/team level/project/time/money/existing stack
I’m trying to incorporate kmm as well and it seemed we were good with all corners, but when you dig it deeper you meet the problem mostly on ios side with IDE highlining, you’d wand to get support of swift, better naming, auto-complete code and… you understand kmm beta is not ready to hard enterprise, but if you can afford it why not to try

[darkmoon_uk]

IMO The biggest/broadest 'problem' facing KMM adoption today is not the hard viability of the technology - which does work. From experience the problem is a human one: of finding the right developer(s) who are both skilled and willing to work on the iOS side.

I've seen the extreme end of this first-hand: I was in one scenario where a developer joined our KMM team but for some reason, only after joining, found himself unwilling to learn Kotlin and so kept tinkering around the edge with improving Xcode configurations, or producing Swift versions of the UIViewModels and asking if we could integrate those (against the architecture of the project). Eventually things came to a head and I asked him directly 'are you willing to learn Kotlin Multiplatform'? 'No' came the answer. Fortunately I didn't have to deal with that answer as the project manager stepped in.
That manager didn't even fully understand KMM himself but saw correctly a developer who was unwilling to adapt to the needs of a project - if it was KMM today it could be another technology tomorrow. He was let go the next day.

We were clear that this was a KMM project from the beginning and offered plenty of learning support/sessions. Another couple of Devs had no issue, but some personalities may struggle with their own dogmatism.

[darkmoon_uk]

This experience weighed on me, going into this second major KMP project that I'm in now; but fortunately the experience couldn't be more different. All the Devs involved are highly skilled and supportive of the vision. ✨

[Martina Rauert]

Thanks for the feedback everyone 👍

That is a good point, about the people problem and finding the right devs for the project. To clarify, it sounds like you’re using KMM in your product day-to-day, is that right? May I ask how large of a team/company you are at? Do you find it works well overall for your needs, even though it’s in beta?

I’m just one person looking into integrating it into our workflow at the moment, for my team of about 15 mobile developers, both Android and iOS.

[darkmoon_uk]

Mid-stage startup; immediate Dev team ~4 developers; with a pool of around 15 devs who could be swapped onto the project as needed. For the core KMP part, Beta is a non-issue, it works. We get involved in the bleeding edge where we try to use things like Composite builds for Gradle to improve our workflow. But the Devs who are taking care of that side don't sweat it because it's not on the critical path; we're just enjoying seeing the potential of KMP grow at the same time as benefiting from the already solid core.

[darkmoon_uk]

There's an iOS integration where we had to make an ObjC wrapper; due to lack of direct Swift interop. That's another trade-off; but we understood it well enough going in, due to experience with most of those moving parts, and it is so far working out OK.

[darkmoon_uk]

I've come to the opinion that early adoption of tech like KMP/KMM is one of those questions that holds its own answer: if you think it's not for you - it probably isn't. If you're experienced enough with the surrounding technologies already, to have the level of confidence it takes to ride the rough patches; then you're probably not going to be asking the question in the first place. And yes, even then some curve-balls can make you sweat, but there are nearly always workarounds 🙂 (and a very helpful community ❤️). As with many endeavours, a shortfall of experience can be made up for with enthusiasm and willingness to learn on the go - but the team have to be on board.

[Pablichjenkov]

Definitely you gotta weigh the human capital, is an edge technology that not everyone is ready to deal with.

[Pablichjenkov]

It requires architectural knowledge but you gotta know how to play down the "bitcode" too.

[russhwolf]

If you're exploring using KMM in existing apps, you might not be asking the right questions. Think about what it looks like to introduce a small amount of shared code and incrementally grow from there, rather than trying to solve all the hard problems at once. For example:

Would need to replace the API Client library we currently use with KTOR

That's not necessarily true. You could instead write a shared Kotlin interface that calls into your existing API Clients. This lets you write shared logic that can make API calls, without throwing away your existing code, and avoids introducing new bugs into your API client that your existing code has already solved.

Mocking was not possible in the iOS env

I bet your iOS engineers have strategies to deal with this. Maybe the tests in your shared code will look different than your Android code. Don't think of KMM as taking everything you have on Android and using it on iOS. Think of it as bringing the teams together and find the patterns that work for everyone.

[Martina Rauert]

Thank you every for your input! This is all super helpful!

You could instead write a shared Kotlin interface that calls into your existing API Clients. This lets you write shared logic that can make API calls, without throwing away your existing code

The main problem we’re trying to solve with KMM is to remove code duplication between our platforms, and I don’t see a way around pivoting to KTOR. Overall, you’re right - we could write a shared interface and leverage the existing Android implementation, but this cannot be used for the iOS implementation as it depends on the JVM. If we have to rewrite the API library in the iOS implementation that does not satisfy our requirement of duplicated code per platform.

Unless I’m missing something obvious - I am not an Android developer by nature so I could certainly be overlooking something!

Think about what it looks like to introduce a small amount of shared code and incrementally grow from there, rather than trying to solve all the hard problems at once.

I definitely need this reminder from time to time 😅 thanks!

[russhwolf]

For the API client, I was assuming you also have an existing iOS implementation that you could wrap behind the same interface without needing to rewrite much. That would let you share code that talks to your API clients, which would be helpful if you have a lot there already (or plan to). But if you're frequently writing new endpoints and making changes to the API client configuration, then you'd get less of a benefit.

My general suggestion is to start with the refactors than enable you to share the next bits of code you want to write, but don't be afraid to leave platform-specific pieces in place if they're battle-tested and doing what they need to currently.

[Martina Rauert]

don’t be afraid to leave platform-specific pieces in place

I am definitely approaching KMM in the exact opposite way to this, so that is something I can work on 😄

Thanks for clarifying! It is super helpful!