Damn this kind of breaks both my legs

# multiplatform

[Lucas Schiavini]

Damn this kind of breaks both my legs

[Lucas Schiavini]

I'm gonna test this out to see if it matches my needs https://johnoreilly.dev/posts/kotlinmultiplatform-swift-combine_publisher-flow/

[John O'Reilly]

Hi Lucas, It may not suit your needs but more recently I've switched to using new async/await etc provided in Swift 5.5. along with following library https://github.com/rickclephas/KMP-NativeCoroutines

[John O'Reilly]

(also btw using new K/N memory model now in most projects)

[John O'Reilly]

wrote a bit about using that library in https://johnoreilly.dev/posts/kmp-native-coroutines/

[Rick Clephas]

Unfortunately concurrency interop is one of the biggest limitations (especially now we have Swift concurrency). IMO using wrappers is currently best “solution”.
And… what @John O'Reilly said 😂 😇

[John O'Reilly]

a good number of the samples at following are using that library now https://github.com/joreilly

[Lucas Schiavini]

@John O'Reilly Do you think this library for kmp coroutines is production ready?

[John O'Reilly]

@Rick Clephas , as library author, can probably comment in more detail 🙂 , but fwiw seems to work great here. The integration with new swift async/await, AsyncStream etc is really nice ....particularly when mapping to flow in shared code and using appropriate hooks in SwiftUI to invoke async code along with automatic cancellation. you get (which is propagated down to flow)

[John O'Reilly]

Personally I'm hoping this library could get integrated in to core Kotlin/Native offering as it, along with use now of new memory model, would make interop so much more seamless (any Jetbrains folks out there that can comment on whether this could happen? 🙂 )

[Rick Clephas]

I would say that the core of the library is production ready (meaning the way Flows/suspend functions are mapped to Swift types).
However the compiler plugin that automatically generates the wrapper functions has some issues (it can cause recursion errors during compilation), but there are workarounds.
Besides that there is only 1 thing I would really like to improve before officially calling it production ready: https://github.com/rickclephas/KMP-NativeCoroutines/pull/49
I have actually started tracking the these things here: https://github.com/rickclephas/KMP-NativeCoroutines/milestone/1

[Rick Clephas]

Definitely hoping that we can integrated this in the Kotlin/Native ObjC interop. Unfortunately I am not that familiar with LLVM, etc. But I would definitely say that it is possible!

[Lucas Schiavini]

@Rick Clephas I'm curious to know what would it take to create the llvm bridge

[Rick Clephas]

Well there is 1 big challenge and that is the absence of kotlinx.coroutines (which is currently used to run/collect suspend functions and flows).
Besides that it should be fairly straightforward (I think). During the ObjC header export coroutines functions/properties should be transformed into lambdas.
After that the invocation of such declarations should should be intercepted and “transformed” into invocations to the wrapper functions (like nativeSuspend).

[Rick Clephas]

I mean suspend functions are already transformed into functions with completion handlers, so they “just” need to be transformed a little differently.

[Rick Clephas]

That is for Kotlin to Swift interop. Swift to Kotlin interop is a whole other story 😇

[hfhbd]

https://youtrack.jetbrains.com/issue/KT-51297

[rudolf.hladik]

You can also check out Arkitekt library . It wraps flows and suspend functions in UseCases. I don't really see the point of wrapping flow to another stream 🤷

[Rick Clephas]

I think it just depends on the project and your requirements. The goal of KMP-NativeCoroutines is to improve the interop between Kotlin and Swift in terms of async code.
Allowing Swift developers to use Kotlin async code in a "native" way, without making any assumptions about the application architecture. You could even use it with UseCases if you like.