Hi guys, Just a curiosity for the authors. Regardi...

# orbit-mvi

[Guilherme Delgado]

Hi guys,
Just a curiosity for the authors. Regarding your KMM implementation, have you looked into https://github.com/rickclephas/KMP-NativeCoroutines or you don’t want this kind of dependency in your framework?
I’m doing some tests by managing it by myself and now I’m trying the same but using KMP-NativeCoroutines. What are your thoughts about it?

Thanks!

[Benoît]

I've been using KMP in prod for a while, I've never encountered any problem like that simply because I don't expose suspend functions to iOS.
The way we support cancellation is by having iOS passing a CoroutineScope to any function that uses coroutine, then it's easy to simply call cancel() in Swift where needed

I'm not saying it's the best solution, but it works well

[Guilherme Delgado]

Yes, I’m doing something similar to this: https://github.com/orbit-mvi/orbit-mvi/blob/main/orbit-core/src/iosMain/kotlin/org/orbitmvi/orbit/Subscribe.kt
But the KMP let us use combine and async in a “automagically” way: https://github.com/joreilly/PeopleInSpace/blob/main/ios/PeopleInSpaceSwiftUI/PeopleInSpaceSwiftUI/ViewModel.swift

would like to know if anyone bumped into some pros/cons of both approaches

[Guilherme Delgado]

@Benoît I’ve read again your response and I realise I was making a confusion 😅 . Orbit doesn’t use suspend fun, instead uses Flows. But KMP-NativeCoroutines also supports Combine (“Flow”) logic and my question was related to those.
So, perhaps, for orbit, there’s no need to use it, since the gradle plugin is based on this approach: https://johnoreilly.dev/posts/kotlinmultiplatform-swift-combine_publisher-flow/

[Benoît]

I have my own version of KotlinNativeFlowWrapper it's a very minimal class I'm okay to live with, I don't think there's the need for importing a whole library.
But then as always it depends on your use cases, in my experience, it's always possible to nicely abstract coroutines away for iOS but I haven't done anything crazy with it