Is this the right place to ask about kampkit? I re...

# touchlab-tools

[Michal Klimczak]

Is this the right place to ask about kampkit?
I read a few articles on touchlabs blog and generally agree with the "share source code, not binaries" reasoning. However kampkit seems to promote cocoapods integration? Which Im not too keen of, cocoapods seems to be superseded by spm in the community and goes against the "share source" etc.
So what would be the go-to production-ready deployment setup. I thought something like what I am trying to do here https://kotlinlang.slack.com/archives/C3PQML5NU/p1729265246106419?thread_ts=1729265246.106419&cid=C3PQML5NU but now I'm a bit confused

[kpgalligan]

KaMPKit is a monorepo layout. It's not set up in the way I'd recommend for existing teams and apps. It's original goal was more focused on basic architecture and not how a team would add kmp. That's a whole different lane of content https://touchlab.co/kmp-teams-intro

[Michal Klimczak]

this one I have not read, thanks 🙂

[Michal Klimczak]

On no, just when you were to reveal the solution! https://touchlab.co/kmp-teams-scaling-howto 😄

[Michal Klimczak]

But from the previous articles I assume the recommendation is to go with multirepo but including GitPortal to stay in control between the teams

[kpgalligan]

But from the previous articles I assume the recommendation is to go with multirepo but including GitPortal to stay in control between the teams

I think the general approach of not forcing the teams to step on each other in the same repo is the overall recommendation. GitPortal has limited features right now. The purpose was to cut down on dev time and edge case issues, then get feedback and add features as they make sense for real teams.
Right now, you can have one cross-repo tracking branch, generally main. Each commit to an app repo's main that changes KMP code pushes a change to the shared repo. It'll certainly work, but there may be alternative ways to accomplish the same thing.
Summary, GitPortal is new, but that is the general model that I think would work well for teams. Feedback appreciated.

[kpgalligan]

The project setup needs to be thought through a bit. The GitPortal tutorial had a good layout for Gradle config.

[kpgalligan]

Also, GitPortal and bidirectional only makes sense for teams who have specific goals for KMP. That's part of the docs and content as well.

[Michal Klimczak]

After reading a few of your articles I feel that for my team's use case we will go with sharing the source for sure and will start with monorepo and move towards gitportal or similar "git submodule" setup once we understand how ios and android devs work together. Where I see the main advantage of the "submodule" over pure monorepo is mostly around possible different pace of ios and android teams, but that still means that we need to work out a system for moving forward with the shared module without breaking it for either of the native teams and I'm not yet sure about this part tbh. Without it, stepping on each other's toes seems to be inevitable regardless of whether the shared module lies within the monorepo or a separate one 🤔.

One thing that prevents me from going with gitportal yet is that from Readme I understood that there's no source code for it yet and that feels a bit risky, even though I understand where that comes from.

Btw we've built a production app ~3 years ago and the go to strategy was for the shared code to be ahead of the apps 😅. Not scalable as you need someone who really understands what "domain layer" is, to prepare all the right shared interfaces ahead of time and it's a rare skill ;).

Always appreciate discussions with you Kevin!

[kpgalligan]

Where I see the main advantage of the "submodule" over pure monorepo is mostly around possible different pace of ios and android teams, but that still means that we need to work out a system for moving forward with the shared module without breaking it for either of the native teams and I'm not yet sure about this part tbh. Without it, stepping on each other's toes seems to be inevitable regardless of whether the shared module lies within the monorepo or a separate one 🤔.

This is essentially the problem I'm focused on. Each team should be able to edit their app and KMP code without being immediately locked into the other team's changes and workflow.

that still means that we need to work out a system for moving forward with the shared module without breaking it for either of the native teams and I'm not yet sure about this part tbh.

That is what GP bidirectional intends to do. The "system" is that if, for example, the Android team made some changes that impacted KMP, an iOS dev would use GP to pull those changes into a local dev branch. they'd implement and test/fix anything for iOS. When merged, there will be changes that an Android dev will then need to review later, but presumably they wouldn't impact Android, so that should wrap up the bouncing back and forth.

[kpgalligan]

You can use git submodule but I don't know many devs who enjoy submodule. You'll also need to figure out a branching strategy across repos that manages changes between apps. That is effectively what GitPortal does. If you make KMP changes in the Android app, those get pushed to the KMP repo, but not directly to main. There's a tracking branch for Android and one for iOS. Eventually, as changes from each app get pulled into the other app, the KMP repo's main advances. You could use submodule to do something similar, but submodule forces it's complexity directly on the dev, and you can get into trouble with it.
There's a version of GitPortal that I wrote as a POC which uses git subtree. If you're going to write your own solution, that's another option, but subtree has it's own issues.

[Michal Klimczak]

Oh I'm one of them, hate git submodule ;) hence the quotes, wrote it as a representation of a class of solutions and in particular meant gitportal as soon as it's ready to be used - lack of open source is something that I fear a little bit

[Michal Klimczak]

I encountered an issue and wonder if you have some experience with that.

We build our ios apps from feature-based packages via spm, e.g. an ecommerce app would have a cart package, product list package, checkout package etc.

shared module contains all domain classes so it should be included in all the feature packages. But a quick research says, that spm is not really compatible with fat frameworks which are built with embedAndSignAppleFrameworkForXcode. So instead we should be using xcframework. Which is not a big deal from the perspective that we talked about before, however it does make the building process a bit longer.

[kpgalligan]

But a quick research says, that spm is not really compatible with fat frameworks which are built with embedAndSignAppleFrameworkForXcode. So instead we should be using xcframework. Which is not a big deal from the perspective that we talked about before, however it does make the building process a bit longer.

Local dev vs wider packaging does tend to require different build configs. Hard to avoid. I'm not sure exactly how you're building the feature packages (in general, not just KMP), but if they get deployed as versioned builds, I think you'd need a rebuild anyway. embedAndSignAppleFrameworkForXcode will only build the arch you need at that moment. Assuming everybody has a mac and none are Intel, you need to build at least two "flavors" of KMP: arm simulator and arm device. Also, you'll probably want to have those published builds as release builds. In that case, whatever was being built locally with embedAndSignAppleFrameworkForXcode would be useless anyway, as it's almost certainly a debug build.

[kpgalligan]

I did a quick scan through the convo again and don't see KMMBridge. If you're going to publish SPM, I'd strongly suggest taking a look https://github.com/touchlab/KMMBridge. That's what the library does. I haven't found a good doc on publishing KMP with SPM outside of KMMBridge. For the docs/posts that would actually even function, it's a lot of manual work. Some docs are technically incomplete or just wrong. KMMBridge has a template lib and various tutorials. We are probably doing an update on those soon as well.

[Michal Klimczak]

Those feature packages are local and just a way of structuring code, like gradle modules for separate features on android. They still utilize spm for packaging but are shared source in the same repo, not versioned packages.

I will read on kmmbridge, thanks!