KMM - Monorepo or Multirepo? Hi all. In the last ...

# multiplatform

[Alen Kirm]

KMM - Monorepo or Multirepo?

Hi all. In the last weeks as we’ve been setting up our KMM project, we came across interesting debate about which repo approach should we use - mono repo or multi repo.
What are you guys using in your KMM projects? Are there any issues you’ve faced that made you switch repo from mono to multi or vice versa?

Both of these approaches have its own pros and cons, but I see more pros in using multi repo approach (shared logic added as a git submodule into ios/android repo):
• smaller repo size (specially in the future there may be platform specific binaries in the repo, same goes for assets…)
• platform specific CI settings, versioning (tags), pull requests and branches
• no need to clone whole project, specially as there are some guys on android and some guys working on iOS project
• in the future there might be other platforms using shared module and having all platforms in one repo does not make sense IMO.
• and so on
One challenge is, how to assure “green-develop/master” on shared module. We’ve been thinking about approach where some feature will be implemented, and there will be changes on common repo. We could probably open a pull request and once tests and everything is green, git workflow could open PR’s for iOS and Android as well.


Any opinions, feedback how you guys face this? What are best practices for huge projects?

[hfhbd]

We use a mono repo, because this allows anybody to simple go to the definition, see it and change it. Otherwise, there is a invisible border. Also with a mono repo, you dont need a local artifactory and every build is compatible, with the downside of longer builds and larger repository.

[eygraber]

https://kotlinlang.slack.com/archives/C3PQML5NU/p1641434419002400?thread_ts=1641434419.002400&cid=C3PQML5NU

[Yev Kanivets]

We've used two repos structure for two years, but it adds a lot of friction from the iOS side - to make any change (esp. debugging) in the common part, you need to do it in Android repo, create PR, merge it, and only then align on iOS. iOS is always catching up. No possibility to change common part on iOS. No possibility to develop Android and iOS in parallel.

So we've migrated to monorepo a few weeks ago and it feels to much better.

[Miguel Vera Belmonte]

My take, though it’s not with KMM, but rather KMP: we used to have a multi-repo approach, with a sort of root repo that added all its dependencies as Git submodule references (you could say that was sort of a monorepo as well). This was in a project that had many K/Common modules, many K/JVM modules and some K/JS ones. We transitioned from this to a true monorepo approach, mainly because of:
• difficulty of introducing junior developers to the codebase (particularly Git submodules were a pain).
• ease of refactoring; in IntelliJ, you can rename one class in a common KMP module and every dependent module reacts to the change. With a multi-repo approach this is impossible and requires a considerable amount of work.
• everything is accessible, you can click a class in another module and the IDE takes you to it to inspect it.
• no need for the usual library publish/release cycles if everything is in the same repo (with the added downsides of this, ofc).
We use GitHub actions, so for us it was as easy as adding a rule to execute particular CI actions only when files under particular folders were modified.

[Alen Kirm]

@hfhbd @eygraber @Yev Kanivets @Miguel Vera Belmonte
Thank you guys for your replies and help!
So conclusion is, you are mainly using Mono repo approach, due to easier refactoring and easier access to files within modules. That’s a good point.

Guess we’ll try it out with Mono repo approach and we’ll se how it goes. Although, we have a “custom Dependency Manager” on iOS, which creates XCFramework for specific configuration and adds it into a project (as static framework). There is an XCode target for this action, so this will also be run on CI, before making Xcode Archive. How are you distributing it into Xcode project? SPM, Cocoapods?

Thank you once again for your replies!

[David Nedrow]

I had been using a mono repo but with recent changes in the layout, we've switched to a multi-repo. Gradle as a build tool for iOS was just too much trouble. And the lack of an Xcode project was frustrating for devs who wanted to use Xcode for the iOS work.

[David Nedrow]

We used SPM for dependencies initially, but we have some thrid party libraries that want to clutter our project up with a workspace, so avoiding CocoaPods was no longer necessary.

[Alen Kirm]

@David Nedrow Thank you for sharing your experiences!

[Yev Kanivets]

@David Nedrow monorepo doesn't mean no XCode project. We are using XCodeGen to generate our XCode projects + prebuild script to build common iOS framework and embed it in the iOS app. From iOS development perspective there are almost no change aside the framework with common code to be used.

[Yev Kanivets]

I'm actually working on the article to share our takeaways if you want more details.

[David Nedrow]

Aha. I figured out what was happening. If you use AppCode 2022.1 EAP to generate a new KMM app, no Xcode project is created. That's a bit baffling. I wonder if there is an expectation that the dev would need to create a project (XCodeGen?) and write the necessary build phases.

[David Nedrow]

Found this in YouTrack: https://youtrack.jetbrains.com/issue/KT-41529