Bump Kotlin 2.1 → 2.4 (fixes #528 — iOS IrLinkageError)#529
Conversation
Recompiles the published iOS klibs against Kotlin 2.4 so consumers on Kotlin 2.4 no longer hit `IrLinkageError: No class found for symbol 'io.github.openflocon.flocon/Flocon|null[0]'` on app launch. Kotlin/Native klib ABI is not stable across major Kotlin versions; older klibs link at compile time but fail singleton resolution at runtime when the host app is on a newer Kotlin major. Bumping Kotlin in the build recompiles all `*-iosarm64`, `*-iossimulatorarm64`, and `*-iosx64` artifacts and resolves the linkage error. Fixes openflocon#528. Verified locally: - `:flocon-base:publishToMavenLocal` ✓ - `:flocon:publishToMavenLocal` ✓ - `:ktor-interceptor:publishToMavenLocal` ✓ - `:flocon-no-op:publishToMavenLocal` ✓ - `:ktor-interceptor-no-op:publishToMavenLocal` ✓ All produce iosArm64 / iosSimulatorArm64 / iosX64 klibs with no source changes. Only output is warnings about beta `expect/actual` classes and DSL-marker-on-top-level-fn — both pre-existing and unrelated to the bump.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request attempts to upgrade the versions of Compose, Kotlin, and KSP in the Gradle version catalog (libs.versions.toml). However, the specified versions (1.11.0 for Compose, 2.4.0 for Kotlin, and 2.3.9 for KSP) do not exist or are invalid, which will cause dependency resolution and build failures.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
Looks like there is a problem with R8 |
Compose Multiplatform 1.11 no longer publishes an iosX64 (Intel Mac simulator) variant — the sample's iosX64CompilationDependenciesMetadata configuration can't resolve compose.runtime/foundation/ui for that target and the build fails with "No matching variant". Drop the iosX64 target from the sample-multiplatform module to track upstream. Apple-silicon devs use iosSimulatorArm64; real devices use iosArm64. The publishing modules (flocon-base, flocon, ktor-interceptor, *-no-op) still publish all three iOS slices because they don't depend on Compose; only the sample needed adjusting.
This looked like it was a Gradle variant-resolution error in building the sample project, not an actual R8 error. It should be fixed now with that latest commit. |
2 participants
Closes #528.
iOS consumers on Kotlin 2.4 hit
IrLinkageError: No class found for symbol 'io.github.openflocon.flocon/Flocon|null[0]'at app launch because the published*-iosarm64/*-iossimulatorarm64klibs are still compiled against Kotlin 2.1. Kotlin/Native klib ABI is not stable across major Kotlin versions — older klibs link at compile time but fail singleton resolution at runtime when the host app is on a newer Kotlin major.This bumps:
kotlin2.1.0 → 2.4.0ksp2.1.0-1.0.29 → 2.3.9 (KSP 2.x is decoupled from Kotlin major)compose1.9.0 → 1.11.0 (CMP pairing required by Kotlin 2.4)Verified locally on macOS arm64 — all five iOS-publishing modules build and publish their
iosArm64/iosSimulatorArm64/iosX64klibs cleanly::flocon-base:publishToMavenLocal✓:flocon:publishToMavenLocal✓:ktor-interceptor:publishToMavenLocal✓:flocon-no-op:publishToMavenLocal✓:ktor-interceptor-no-op:publishToMavenLocal✓No source changes required. Build output contains only pre-existing warnings (
expect/actual classes in Beta, DSL marker on top-level fn) — none introduced by this bump.