hey guys, we found out it's really a great pain to...

# multiplatform

[Marc Neureiter]

hey guys, we found out it's really a great pain to integrate the ios project into the android one just to enable kmm because of our ci pipeline setup. and i think it's the same for a lot of the teams out there most probably.

as recommended by jetbrains, the iosApp should live in a repo containing the android app and shared module. in that setup, the ios compiler triggers the shared module's compilation routine. after that, the ios compiler can pick up the artifacts from the parent directory. unfortunately, to make this work in the pipeline, you have to completely adapt its configuration to check out the android/shared repository instead, where the ios repository is embedded. that's a huge task.

one of our co-workers has some experience with setups like these and came to the conclusion that a different way is much easier and requires no changes in the ci pipeline while still having the code of both platforms conveniently in one place, so you can check it out with fleet and do code editing and debugging cross-platform. the solution is simply exactly the other way round as described above: the android/shared stuff is checked out into a folder inside the ios project. that way the ci pipeline configuration can stay the same. it's not only easier to adopt kmp that way, it's also no problem having it like that in general, as we wouldn't mind at all to have a folder shared (containing the android/shared part) inside the ios repo.

i think it's wrong to thinking that, just because "shared" is the new kid on the block, the ios app part needs to be inside the android/shared part. i think easy adoption and relative independency of the ios part from the android/shared part can be key to the adoptionn and success of kmp. we really want to see this option to be an increasingly attractive one for developers and companies everywhere, so we'd be really glad to see this piece of feedback find some reception at jetbrains.

all the best and keep up the really amazing work, jetbrains! ❤️

[Kurt Renzo Acosta]

what worked for me is to have separate branches for CI pipelines. release/<env>/android and release/<env>/ios. They’d contain the same code but easier to keep track on which is released per platform and and i can run its own pipeline depending on the platform. the main branch just becomes the latest code so anyone can just push what’s done. i tried the multiple repo approach but it didn’t work out and i like the mental model of building a mobile app rather than building an android/ios app. it kinda forces engineers to think outside their platforms as well but again it depends so YMMV

[Marc Neureiter]

hm, that's an interesting approach, i'll definitely update my team about it, thanks 🙌

[darkmoon_uk]

It may help to hear that, as a KMP adopter on two commercial Mobile projects myself, I do not recognise the problem you describe...
> to make this work in the pipeline, you have to completely adapt its configuration to check out the android/shared repository instead, where the ios repository is embedded. that's a huge task.
...if I am interpreting this correctly, you're still trying to operate a model of having a separate code repo for your iOS and Android projects? This is absolutely not the KMP model; and yes you'd have a really hard time fighting it, I can't really imagine why you'd want to do that either when the goal is to integrate the two deliverables via shared module as closely as possible. I could imagine keeping shared with one of the platforms and then Git submoduling it into the other but just... why?

Let go of that constraint and I think you'll find it all falls into place.

[gildor]

I'm not so deep in the context, but I would support Chris' question. I cannot understand the problem too

I see two viable approaches:
1. One repo with both apps and with shared code
2. Two apps (separate or different repo, not so important), which both use KMP library as binary dependency, which is hosted again in a separate or the same repo
In both cases I don't see issue with CI setup and shared code base

Maybe you could clarify a bit, I would like to understand what kind of challenges in terms of infrastructure it may cause

[Marc Neureiter]

@gildor with option 2 you lose the possibility to debug conveniently with shared and ios sources opened in fleet, so that was no option for us.

as we're trying out kmp we saw fusing the two platform repositories into one not as an option for now. we know submodules are not a long-term solution. only for when we know we'll go the kmp route for sure, we will switch to a real monorepo approach. until then the approach of having the android+shared part in a submodule is really the way to go in our opinion. that way you have the possibility to use fleet with both repos checked out and no pipeline has to be touched.

was this helpful?

[darkmoon_uk]

You could retain convenient debugging with Option 2, if you use Gradle Composite projects to assemble a 'workspace' of your App and Shared library projects.

[darkmoon_uk]

I would not consider my current project to be a MonoRepo either; we actually do use Git submodules but for a different use-case: to composite-in a Design and Architecture library. These libraries are intended to eventually 'stand alone', while being developed in-line with the main project.

Using Submodules with Gradle Composite affords the flexibility to grow dependencies in-line with a project, then later 'detach' them as more mature binary artifacts, with minimal impact to the main project.

What I would never do is split repositories by platform. This simply breaks the KMP model.

Also, you mention using Fleet but it is simply not 'production ready' in most contexts (being a 'Public Preview').
I'd stick to a combo of IntelliJ / Android Studio / Xcode for now if I were you.

[darkmoon_uk]

Seeing as your requirements are shaped by a need to try out Kotlin Multiplatform in an established project that already has two repo's, I think your best bet is:
• A new KMP shared library in its own repo
• Sub-module the new repo into each App repo
• Composite that shared library into each App project's workspace with Gradle Composite Builds

[gildor]

Composite build though is not synced with project automatically, so sub-module is probably the only viable option. UPD: misunderstood the suggestion, yes, using shared library in a separate repo, use composite build for development, and optionally use binary for other cases

[darkmoon_uk]

Composite and Git sub-module I see as fully complementary mechanisms to one another, in this case:
The shared module can live in its own repo as a standalone Library project.
• Brought into the parent project's filesystem by Git Submodule.
• Brought into the IDE workspace by includeBuild("<repo_path_to_submodule>/myLibrary").

[gildor]

composite + sub-module yes, it's a way to have a separate project for shared library
just composite not really, because there is no information about which commit should use every specific commit of your app

[gildor]

But now I see it's just a list of suggestsions, not different options, yes, it makes sense, updated my message

[gildor]

If debugging doesn't work with Fleet in this case, I would report it first, I don't really see actual technical issues with this approach