Sebastien Leclerc Lavallee
05/07/2025, 3:39 AMexpect/actual
like this:
expect class PlatformUIComponent
// Android
actual typealias PlatformUIComponent = FragmentActivity
// iOS
actual typealias PlatformUIComponent = UIViewController
And I have a service in common code that use that class:
class SomeService {
fun showView(component: PlatformUIComponent)
}
I want to test that function. When I try to call that function in my test, I don't see how to pass an instance of the expected class.
service.showView(compoment = [???])
How could I achieve this?
Thanks!Adam Brown
05/07/2025, 5:54 AMPrakash Irom
05/07/2025, 6:53 AMAndrej Martinák
05/07/2025, 12:01 PMdoInit
vs init
, etc.)
• Needing to rely on third-party libraries (from Touchlab)
• General frustration with the development workflow compared to native iOS development
Resource Allocation Concerns:
• Since the iOS team and their tech lead are not keen on leveraging KMP, nobody is focused on working on the integration of KMP (and making the developer experience better) in the iOS project. The iOS team claims that the implementation and maintenance of KMP takes the focus away from iOS-specific technical tasks. This creates a vicious cycle, where there is no advancement and investment in KMP.
• The learning curve for Kotlin diverts resources from platform-specific improvements
• Input from Android devs is needed if changes in the KMP library are necessary
Long-term Viability Concerns:
• The perception that KMP development from JetBrains has been slow over the past 2 years
• Focus on Compose Multiplatform, which in our understanding is not as important as focus on good developer experience (and using KMP for the domain layer and not the presentation)
• The recent abandonment of Fleet as KMP IDE has raised concerns about JetBrains' commitment
• Uncertainty about investing in a technology that might not receive continued support
The resistance from iOS developers isn't unique to my company. I've talked to multiple tech leads in large companies in my area and gotten basically the same response - Android devs love the idea, iOS devs are against it. Because of this pattern, leaders have decided not to go "all-in" on KMP (storing only some configurations and networking vs implementing actual business logic). I would like to give the iOS team some garranty, that KMP is the right technology to use, but at this stage, it is quite hard to find it (for example the case studies are few and I'd say obsolete).
My questions are:
1. What specific improvements to the iOS developer experience are planned for the next 6-12 months?
2. Following the shift from Fleet to focusing on IntelliJ/Android Studio, what's the roadmap for iOS-specific tooling improvements? Is the focus now on adding Swift support to IDEA Ultimate?
3. When can we expect the first public version of Kotlin-to-Swift export, and what capabilities will it offer initially?
4. Are there plans to simplify the distribution and integration process for iOS applications? E.g. by using Amper or something similar?
5. How is JetBrains addressing the objection that KMP lacks sufficient development momentum?
Thanks for any insights you can provide! Would love to see also some perspective from other people in a similar situation as I am 🙂.Rohit
05/07/2025, 12:24 PMSaksham Srivastava
05/07/2025, 3:25 PMcoolcat
05/07/2025, 4:09 PMMiky Ma
05/07/2025, 6:26 PMpod install
directly? IE it should call bundle exec pod install
or wrap the entire gradle sync in bundle exec
@coolcat Did you find a solution for this? https://kotlinlang.slack.com/archives/C3PQML5NU/p1626901552430600?thread_ts=1626900421.427100&cid=C3PQML5NUursus
05/07/2025, 7:37 PMCarsten Hagemann
05/08/2025, 9:42 AMVíctor Hernández Bermejo
05/08/2025, 5:50 PMralf
05/08/2025, 7:01 PM@Suppress("RUNTIME_ANNOTATION_NOT_SUPPORTED")
solves this problem, but I’d like to do this globally. I tried a compiler argument freeCompilerArgs.add("-Xsuppress-warning=RUNTIME_ANNOTATION_NOT_SUPPORTED")
, but it doesn’t make a difference. Any other suggestion?Harri Hohteri
05/09/2025, 6:33 AMgradlew :shared:build
it failed because of
> Task :shared:linkPodReleaseFrameworkIosArm64 FAILED
e: Compilation failed: Linking globals named 'kniprot_cocoapods_FirebaseAuth0_FIRUserInfo': symbol multiply defined!
* Source files:
* Compiler version: 2.1.21-RC
* Output kind: FRAMEWORK
e: java.lang.Error: Linking globals named 'kniprot_cocoapods_FirebaseAuth0_FIRUserInfo': symbol multiply defined!
I got it fixed by defining the following into cocoapods block:
cocoapods {
version = "10"
ios.deploymentTarget = libs.versions.ios.deploymentTarget.get()
framework {
baseName = "FirebaseFirestoreXXX"
isStatic = !enableFirebasePodsForTests
}
Ie. added isStatic
whenever not running tests from Android Studio and renaming baseName
to something else than `FirebaseFirestore`as I copied the configuration from the firebase-kotlin-sdk project.
This fixed it yesterday but today for whatever reason I’m back to the same error about symbol multiply defined. Any pointers would be helpful.
Running tests from Android Studio work fine. I can build an XCFramework fine, but klib fails again.
Any help would be appreciated, thanks.gavin.hu
05/09/2025, 10:43 AMza_kmm_base
) that includes a dependency on an Objective-C library (za_kmm_oc_lib
) via cocoapods {}
configuration:
kotlin
cocoapods {
version = "0.0.2"
summary = "Za KMM Base Component"
homepage = "xxxxx"
ios.deploymentTarget = "12.0"
pod("za_kmm_oc_lib") {
version = "0.0.4"
headers = "ZAKMMRSAUtil.h"
}
framework {
baseName = "za_kmm_base"
isStatic = true
transitiveExport = true
}
}
Then, I published
za_kmm_base
to a private Maven repository for use in other KMM projects.
In another project, I referenced this library via Maven:
kotlin
implementation("com.za.group:za_kmm_base:0.0.2")
However, during the iOS build process, I encountered the following link error:
php
Undefined symbols for architecture arm64:
"_OBJC_CLASS_$_ZAKMMRSAUtil", referenced from:
in libza_kmm_base.a
ld: symbol(s) not found for architecture arm64
🔍 What I Have Tried:
• Ensured that
• za`_kmm_oc_lib`
• is correctly published via CocoaPods and is working properly in the original KMM module.
• In the Maven-based project, I
• did not configure cocoapods {}
or declare the pod("za_kmm_oc_lib")
again.
• Checked Kotlin documentation and found no clear guidance on CocoaPods dependency propagation when KMM libraries are referenced via Maven.
❗ Key Problem Points:
> Kotlin Multiplatform does not automatically propagate CocoaPods pod()
dependencies when KMM libraries are published via Maven.
As a result, symbols defined in Objective-C or Swift code (like ZAKMMRSAUtil
) cannot be linked in the final project, causing the build to fail.
💡 What I Would Like to Confirm:
• Is there an official recommended approach to propagate CocoaPods dependencies for KMM libraries published via Maven?
• Do I need to manually declare pod("za_kmm_oc_lib")
in every downstream project to correctly link the dependencies?
• Is there any plan in Kotlin Multiplatform to support the propagation of CocoaPods dependencies (transitive pod dependencies)?Robert Munro
05/09/2025, 11:31 AMmartmists
05/09/2025, 3:58 PMHossein Amini
05/09/2025, 4:08 PMMark
05/09/2025, 4:22 PMIdris Ocasio
05/10/2025, 5:56 AMFrançois
05/10/2025, 1:59 PMrobercoding
05/10/2025, 9:49 PMstdlib
and a ksp task.
I cannot find information out there, it seems to be a very unique error.
Error in 🧵
Does anyone know what would cause a build in Xcode Cloud to fail only there? Building the app and executing archive locally works fine 🤔Mark
05/11/2025, 12:43 PM@StringRes Int
in a Android library module that has the KMP module as a dependency.
I thought this might do it, but no luck so far:
experimentalProperties["android.experimental.kmp.enableAndroidResources"] = true
This is pretty important for incremental migration. Perhaps I could dynamically include the strings.xml
of the KMP module in the resources of the Android module?Yaroslav Shuliak
05/11/2025, 12:45 PMbuszi0809
05/11/2025, 4:05 PMandroidLibrary {
compilations.configureEach {
compilerOptions.configure {
jvmTarget.set(JVM_TARGET)
}
}
}
but then I've received a deprecation message that I should use compileTaskProvider
instead. But the issue is that when I migrate to it:
androidLibrary {
compilations.configureEach {
compileTaskProvider.configure {
compilerOptions {
jvmTarget.set(JVM_TARGET)
}
}
}
}
the jvmTarget
is unresolved in here. Has anyone found a solution for this? I'm using Kotlin version 2.1.20
. My opinion is that the root cause of that is because the type of compileTaskProvider
is too ambigous:
val compileTaskProvider: TaskProvider<out KotlinCompilationTask<*>>
jamescodingnow
05/12/2025, 12:19 AMcarbaj0
05/12/2025, 8:52 AMSlackbot
05/12/2025, 1:03 PMRobert
05/12/2025, 3:41 PMDhruv Singh
05/12/2025, 6:20 PMThierry Kh
05/13/2025, 2:09 AM