Has anyone integrated Kotlin Multiplatform in your...

# multiplatform

[shivthepro]

Has anyone integrated Kotlin Multiplatform in your existing ios and android apps ? With two platforms having two different repositories how have you guys integrated kmm and did you guys use any libraries like KMMBridge from touch lab?

[kpgalligan]

Well, I'd say, yes, look at KMMBridge. But I'm from Touchlab. Having said that, trying to build your own binary publishing for iOS is not trivial, so definitely look at KMMBridge.

[kpgalligan]

However, I've written about "integrated Kotlin Multiplatform in your existing ios and android apps" extensively. Depending on your team size and goals, there's a fair bit to consider.
https://touchlab.co/kmp-teams-intro
https://touchlab.co/kmp-teams-use-source
https://touchlab.co/kmp-teams-piloting-vs-scaling

[kpgalligan]

Summary: if small team, and/or you're looking to share some code libraries, it's not too tough. If you have more than a few devs, and the goal is to share higher into the "business logic" stack, such as "view model" code, workflow and repo org becomes a bottleneck.

[FabioCornelli]

Hi @shivthepro
One simple / naive approach we have been using since when we started adopting KMP in a similar scenario is to have the whole android-app repository as git submodule of the ios-app repository.

After that, we created in the android-app a new KMP module named something like :appShared that we use to export the kotlin multiplatform code.

In our case, we exported the kotlin code via the cocoapods gradle plugin because our iOS app already uses cocoapods extensively, but a similar approach can work also when exporting a regular .xcframework.

Last step was to add in the Podfile the reference to the local kotlin podspec, something like this:

#add this to your pod file

pod 'appShared', :path => 'path/to/android-app/submodule/appShared.podspec'

And that is it, from swift code you can import appShared and use kotlin code declarations.

If you use regular .xcframework export method, you need to add reference to appShared.xcframework in your xcode project and configure your build settings accordingly (sorry if it sounds too generic, but i've actually never do it, since we are using cocoapods export method).

This approach might not be the best one in general, but has worked well for us so far.

i'm actually open to listen for a better approach and i will definitely have a look at KMMBridge 👀

[kpgalligan]

This approach might not be the best one in general, but has worked well for us so far.

I'm generally averse to submodules because you can get into trouble if not handled correctly. Not for pulling code so much, but if you changed the KMP/Android code while in the iOS repo, getting that code back into the Android app. That kind of thing. Most devs aren't familiar with updating submodules. That's one of the reasons why we made GitPortal https://touchlab.co/gitportal-for-kmp-tutorial-repo-ci-setup. However, if what you're doing works, don't change it 🙂

i'm actually open to listen for a better approach and i will definitely have a look at KMMBridge 👀

I would actually suggest that you don't. If you're pulling the KMP code into iOS and building from source, that's much better. https://touchlab.co/kmp-teams-use-source We're going to improve KMMBridge and support it, but it's not how I'd recommend teams start, if their goal is to at some point have the iOS devs at least make light edits to KMP.
I'm really curious as to your teams process. Do both teams edit KMP? How do you manage changes? How big is the team?

[FabioCornelli]

Yes submodules can be tricky to manage and keep in sync.
We choose them for the reason you mentioned, we preferred to have the kotlin sources available for the ios devs (and even debug it by launching the iOS app from Android studio🔥) instead of having a binary.

KMMBridge might still come handy to us because often times we are required to share our code to third-party in the form of SDK.
Since the third-party might not be using KMP, using KMMBridge to export our KMP code to .xcframework seems great .

I'm really curious as to your teams process. Do both teams edit KMP? How do you manage changes? How big is the team?

I would say our team is pretty small, ~10 devs developing and maintaining (currently) 3 main apps, all native (so you might count it as 6 apps / projects).
We are spread 50/50 between iOS devs and Android devs with myself and the team leader that develop on both platforms.

As you can imagine, sharing as much code as possible is a priority for us.
So we decided to keep the UI native (SwiftUI & Compose) and share up to the viewModel.
Our workflow usually start by having two branches on both repos named like "feature/xyz".

iOS app "feature/xyz" branch always reference branch "feature/xyz" of android app via submodule.
Android team start developing the scaffold of the viewModel by defining a ViewState (usually a sealed data class) that will dictate the ui behavior via a Flow<ViewState> that is exposed by the viewModel class together with possible viewModel method to execute actions (like viewModel.doSomething() ) .
At the beginning everything is kinda mocked / empty, but this way iOS team can start working on the UI without waiting for the full implementation by the android team.
When some piece of the feature is completed and reviewed by android team, iOS team pull the changes and update the submodule reference and proceed with the development.

So to summarize, we mostly have android team pushing updates and iOS team follow through.
Very rarely a pure iOS dev will edit kotlin code (unless its a very simple / limited edit).

Given that Swift & kotlin are very similar, one of our goals is to gradually have iOS devs being more and more familiar with kotlin, but is still a work in progress.

P.S. in new projects, where we started with KMP, we opted for mono-repo containing both apps 🙂

[kpgalligan]

and even debug it by launching the iOS app from Android studio🔥

Why not debug from Xcode? https://github.com/touchlab/xcode-kotlin

[kpgalligan]

P.S. in new projects, where we started with KMP, we opted for mono-repo containing both apps 🙂

I actually think doing this is a bad idea. Your separate repos/flows is the team model that I think makes more sense, or at least will work better for these kinds of teams. The approach you're taking with iOS devs "unless its a very simple / limited edit" then "one of our goals is to gradually have iOS devs being more and more familiar with kotlin" is the practical approach teams should adopt.

Our workflow usually start by having two branches on both repos named like "feature/xyz".

iOS app "feature/xyz" branch always reference branch "feature/xyz" of android app via submodule.

If I could summarize what GitPortal's bidirectional mode intends to do, it's a branching structure that allows the two teams to share code without forcing them to work in lockstep at every commit. That sounds very much like what you're currently doing. The main issue with a monorepo is that any change to the shared logic immediately impacts both platforms, so features can't land until everybody's completely done. For small teams, it's not a big deal. Small teams just figure things out. Larger teams, and your team in the context of KMP would be "large enough" to qualify, run into workflow constraints.
https://touchlab.co/gitportal-bidirectional-intro
In fact, my ideal process would be to disable the iOS targets in the KMP code when editing for Android. Android engineers can write features fully focused on "Android" and not worry about implementing or breaking iOS. The shared code of those features is then pulled into iOS, and iOS devs who are somewhat experience with light KMP editing can implement the iOS side. If they need to change anything in the KMP as part of that finishing process, those changes can be queried and eventually merged so that the two "worlds" stay in sync. The goal is to not mix everybody together in a way that is counterproductive.

[kpgalligan]

Anyway, at some point I'd love to chat in more detail. Your model sounds pretty much like a functional version of what I'm trying to convince people is a practical model. If you get a chance, look at the blog posts I pasted earlier in this thread. Also if you get a chance, I gave a talk at Droidcon NYC a few months ago about these issues: https://www.droidcon.com/2024/10/17/modern-kmp-adoption-for-native-mobile-teams/. I haven't had a chance to adapt that to YouTube yet. Conference talks are long. I want to really trim that down.

[kpgalligan]

Team adoption has been my obsession for a couple years now, for context 🙂

[kpgalligan]

Just went on a walk and let thoughts sink in. I would like to understand your actual workflow a bit better, but I think this could be modeled a bit differently. Still using submodule, but rather than referencing the whole Android repo, CI could be configured to run a bit of "git magic" to create a branch which would only have the KMP module folder (or folders). The iOS repo could reference that with a submodule rather than the whole Android app. That would:
• avoid having the whole app in the iOS repo (locally, obviously submodule avoids that on the server)
• You would only see a commit history that actually impacted the KMP code, not the Android app as a whole
With some smart branch management, the changes coming from either direction could be managed.
Anyway...

[FabioCornelli]

Hi @kpgalligan
Thanks for all the interesting links, i'll have a more in depth look as soon as i have some spare time.
GitPortal seems indeed an automated way of doing what we are currently doing through submodule and branching convention without the hassle for submodules.
I'll write you in private more details about our team workflow 🙂