Hey, while playing around with Gitportal and our A...

# touchlab-tools

[Benedict Pregler]

Hey, while playing around with Gitportal and our Android app I faced some issues with the setup tutorial and wanted to share my solution and check if someone else tried it out and found some downsides using it at scale.
Currently, we have the “library setup” in place, so the KMP library also has a buildSrc folder and some helper functions in the root build.gradle.kts file. This was not playing well with the setup described in the tutorial. That’s why I looked into Gradle Composing builds which was straightforward to setup. I only needed to add includeBuild("library") to the settings.gradle.kts file and then I was able to reference modules from the KMP library inside the Android project with implementation("com.your.org:kmpModuleA")
An issue I already found was that the build.gradle.kts files of the KMP lib are quite red 😅 but everything was building as expected. I think it’s because we are using the Gradle version catalog for the Android project and the KMP lib and for both projects to reference the version catalog starts with lib. This could be solved when I rename the one in the KMP lib like it’s shown in the tutorial.

[kpgalligan]

The tutorial doesn't really describe converting an existing project. It'll definitely be work. You really want to make the library project be able to build on it's own, or pretty close to it. Not just for iOS. You might want to run CI tests on the KMP library by itself. In library mode, of course. In bidirectional, the KMP repo is mostly just a place to keep track of app-specific changes. I haven't had many people outside of Touchlab try the bidirectional mode yet, though. If anybody reading this is taking a look at that, I'd love to chat 🙂

[Benedict Pregler]

Soon (perhaps this or next week), we want to try out the bidirection mode for the Android project but we think we will not do it for the iOS project because the iOS build time would increase by 1 minute for debug builds and by 5 minutes for release builds which we can not justify right now. After all, not every iOS developer is using KMP, yet. 😉
So we keep the library style for iOS but they will have their own branch and Android will try out the bidirectional mode also with their own branch (as described in the tutorial).
So I can follow up on this next week or so.

[kpgalligan]

the iOS build time would increase by 1 minute for debug builds and by 5 minutes for release builds which we can not justify right now.

First build, unless you're changing the Kotlin, of course.

After all, not every iOS developer is using KMP, yet.

Well, if the goal is to get the team to use KMP. Maybe not making heavy edits, but being involved, I (personally) think it's better to get them to at least install the tools. Again, first build adds a minute, but after that, it should be fast. This also gives them the ability to browse and debug from Xcode. Blog post on this concept: https://touchlab.co/kmp-teams-use-source

So we keep the library style for iOS but they will have their own branch and Android will try out the bidirectional mode also with their own branch (as described in the tutorial).

So I can follow up on this next week or so.

I am curious about this. I'll think about the scenario. I guess you could set things up such that:
• Android is bidirectional. Basically, Android devs don't worry about iOS. I'd even use Gradle tricks to remove the iOS targets, so the Android devs don't have to worry about failed builds if the iOS side isn't implemented
• iOS uses a published library by default
• Configure the local iOS build setup to be able to use source directly. Then an individual developer could pull from the KMP repo using bidirectional. They implement the iOS side for a few features that the Android team had added. Once finished and the PR is approved, run a CI publish build.
• Once that is merged, the rest of the iOS team gets the published CI build, but the actual process of KMP dev underneath is using bidirectional. Just not everybody on the team.
Ping me before you start. Library/unidirectional was simple (relatively) to implement. Bidirectional was not, and I put in a lot of constraints. The idea was I'd rather get feedback and add features as people request then. Trying to "guess" which git operations people would need would've blown up the feature set and dev time.