FYI — if you use Kotlin/Native and moko, you will ...

# moko

[kevin.cianfarini]

FYI — if you use Kotlin/Native and moko, you will be unable to upgrade to Kotlin 2.1.0 and have tests pass and will be unable to upgrade any dependencies that are built with Kotlin 2.1.0. It’s a forwards incompatible change for Kotlin/Native, meaning that libraries built with 2.1.0 cannot be consumed from 2.0.X.

See more here: https://github.com/icerockdev/moko-resources/issues/796#issuecomment-2575750611

[Marcel]

Do we know if anyone is actively working towards a solution to this issue? Our team just stumbled on this issue today after upgrading to Kotlin 2.1.0

[kevin.cianfarini]

I’m currently unsure, and as a result our work team has started pulling moko out of our codebase. It’s unfortunately blocked our Kotlin upgrades too many times and is too much of a liability.

[Marcel]

That is indeed unfortunate. We decided to add Moko resources because we don't have a mono-repo with KMP and iOS, and using Compose Resources was not possible having a multi-repository approach and generating an XCFramework library that bundled the resources...
Moko was the only thing we found that solved that use case for us. Hopefully, we can find an alternative solution 🤞

[kevin.cianfarini]

Yup, we used it for the same reason. The solution we’ve ended up with is to not use strings in shared code, and instead allow the UI layer to render a data description of some state to strings.

[kevin.cianfarini]

It required mapping on both platforms, but is much simpler from an infrastructure front.

[Marcel]

It's a good point. So essentially, you have an ID representation of the string on shared and then the translations available on each of the repos?
What about images or fonts? Do you use them on the shared code? We are using Compose Multiplatform for some screens and I'm not sure if they will be a problem if we get rid of Moko resources.

[kevin.cianfarini]

No, we describe our presentation state as data. Eg:

sealed class DateLabel {

  object Today : DateLabel
  object Yesterday : DateLabel 
  class Absolute(val date: LocalDate) : DateLabel
}

The UI layer will render R.string.today and R.string.yesterday for the two fixed cases, and will use a proper date formatter for the Absolute case.

[alex009]

if you have time to reimplement moko-resources from scratch in your project so i think better will be fix issue in moko-resources and send pr that will fix it for all users too?

requests from community is big help. i have small amount of time, but try to push fixes in new versions when i can

[alex009]

for case

w: KLIB resolver: Skipping '/Users/runner/work/Flapjack/Flapjack/.ci-gradle-home/caches/modules-2/files-2.1/com.squareup.okio/okio-iossimulatorarm64/3.10.1/bf082b70caf16fc3896370a0fdd633610c89b4f4/okio-iosSimulatorArm64Main-3.10.1.klib'. 
Incompatible ABI version. The current default is '1.8.0', found '1.201.0'. 
The library was produced by '2.1.0' compiler.

i think you can try to force gradle to use okio with your valid version.
and i not see why this issue relates to moko-resources at all - update 0.24.4 not change any dependencies versions and compiled with kotlin 1.9.20

[alex009]

i will check reproducers from this issue on weekend

[kevin.cianfarini]

> and i not see why this issue relates to moko-resources at all - update 0.24.4 not change any dependencies versions and compiled with kotlin 1.9.20
This issue is related to moko because it is incompatible with Kotlin 2.1.0 currently since that version breaks iOS testing. I was merely stating that moko being incompatible with Kotlin 2.1.0 has stopped us from upgrading, and since libraries in the wider ecosystem are updating with a forwards incompatible LLVM version, then the choices we’re left with are:

• Let our dependencies atrophy while we wait for a compatible moko release that resolves this issue.
• Start decoupling ourselves from moko so that we can upgrade Kotlin on our preferred timeline.

[alex009]

0.24.5 released, please check