Hey folks! :wave: I’m building a Kotlin Multiplatf...

# multiplatform

[dhia chemingui]

Hey folks! 👋 I’m building a Kotlin Multiplatform (KMP) SDK where I am writing both the shared KMP library and the iOS Swift implementation of our core interfaces.
I am connecting them using an internal factory closure that maps the Swift implementation back to the shared KMP interface. The iOS side passes this closure internally during the setup phase, and the KMP factory methods use it to instantiate the API.
A few key details here: the iOS APIs I am using are written entirely in Swift (not Objective-C), and I have no Swift Package Manager (SPM) support available for direct dependency linking.
I wanted to ask the community about potential pitfalls with this specific setup:
1. Did you use a raw Kotlin lambda for this internal closure?
2. Are there any hidden threading or memory pitfalls I should watch out for when Kotlin background coroutines invoke this internal Swift factory closure?
3. Since the underlying iOS APIs are written only in Swift and we don't have SPM support, what is the cleanest way to handle the module organization and compilation so the Swift target can implement the shared KMP interface smoothly?
Would love to hear your experiences or any architectural tips for managing this bridge! 🚀

[mohamed rejeb]

Are you doing this to be able to use some APIs from a swift package using SPM?
If so now you can import swift packages as dependencies in kmp without any swift code.
It's experimental since 2.4.0-Beta, currently you can use 2.4.0-RC2
And it's working fine

https://kotlinlang.org/docs/multiplatform/multiplatform-spm-import.html

[dhia chemingui]

Yes, I'm a bit confused. The documentation expects a package URL, but in this case these are internal Apple APIs written in Swift. I'm not sure whether that would work the same way here. What do you think? for example (https://developer.apple.com/documentation/familycontrols)

[dhia chemingui]

@mohamed rejeb I created a Swift wrapper and exposed the classes via SPM by using localSwiftPackage. It works, but I haven’t fully tested it yet. So far, it seems fine.

[dhia chemingui]

Thanks, you made me rethink it.

[mohamed rejeb]

Ah that's a different thing, well this should work I guess. Good luck on that

[mohamed rejeb]

Also you may want to try cinterop. I think it's a better approach for your case.

https://github.com/MohamedRejeb/Calf/blob/main/calf-webview/src/iosMain/cinterop/nskeyvalueobserving.def
https://kotlinlang.org/docs/native-objc-interop.html#forward-declarations
https://medium.com/@shivathapaa/bridging-swift-to-kotlin-multiplatform-a-complete-guide-to-cinterop-in-multi-module-projects-af54d88f4b4f

[russhwolf]

I haven't looked at it in a while, but iirc KMPNativeCoroutines uses a similar structure to 1. where it uses lambdas to link between Kotlin and Swift internally. So that might be something to look at for comparison if you need it.

[François]

Take a look at spmforkmp

[dhia chemingui]

Thanks folks,
When you deal with modern Swift, you aren't just fighting the opaque types; you are also fighting Concurrency Models.
If you go the raw cinterop route, Kotlin cannot natively await a pure Swift async/await function. To make it work, you are forced to write a tedious, boilerplate-heavy native Swift wrapper that converts every modern async call back into old-school Objective-C completion handlers (callbacks).
Also now that SwiftSPM* moved to alpha*, it feels like we’re getting close to a more production-ready workflow for this kind of setup 🚀
I just discovered a sad little detail: the Screen Time API requires an Apple Developer membership to actually work… Apple really said ‘pay to play’ 😄”

[François]

You mean like this playground https://github.com/frankois944/Swift-Import-Interoperability-with-Kotlin-Multiplatform ?