Hey guys, remember Koru - library which generates ios wrappers for coroutines? It's now rewritten with KSP and has a compiler plugin for easier setup. Have fun and let me know if there are any issues. https://github.com/FutureMind/koru

Hi @Michal Klimczak, looks great from a first read. Until today I have been using @Rick Clephas ’ KMP-NativeCoroutines Both look pretty similar. Do you have any hint for me why I should use one over the other? Wouldn’t it make sense to team up with Rick? Or Rick with you?

The main difference, I think, is in the API. Rick's generates wrappers for all your suspend functions and flows automatically (and you can opt out with annotation), Koru requires you to be explicit about what to wrap. Koru doesn't provide the swift side (because it's pretty simple and you can just copy it from the sample app), but I'm planning on adding it. What might be interesting in Koru for some people is that it allows to generate wrappers for both your interfaces and classes extending them and automatically matches them, which makes exposing it as protocols in swift for e.g. faking in tests and generally POP easier. Not sure how KMP-NC handles that. And it also allows you to choose if you want to freeze the wrapper or not (which is no longer a big deal, now that we have new memory model). When it comes to joining forces, I would love that, but the main problem is that the internals are pretty different. Koru is based on an annotation processor (ksp now, previously kapt), it generates source code. KMP-NC is a compiler plugin (CommandLineProcessor), which I'm not really familiar with, but afaik it modifies the bytecode rather than generating source code. KSP might make it more future proof, because it is supposed to heavy-lift all the bytecode compatibility stuff. But for now it's still under heavy development, so the compatibility between different versions of kotlin seems to still be a concern for Koru. It seems to handle compatiblity with different versions of coroutines well, though (regular, native-mt, new-mm and whatnot). Hope that clarifies it a bit. Would love to hear from Rick about his thoughts.

Thanks for this very detailed answer. Makes total sense to me. I'll give Koru a try a and see for my self, which is best for my use case.

Sure, any feedback after you try is appreciated

Agreed, the difference is in how coroutines are exposed. Koru generates wrapper classes where KMP-NC leverages the Kotlin-ObjC interop. By using the interop KMP-NC can provide Swift implementations that don’t depend on your shared Kotlin code. The native classes generated by Koru allow you to create Swift implementations, which isn’t currently supported by KMP-NC. I should note that the compiler approach used by KMP-NC isn’t fully supported (there are some issues with recursion errors during compilation). Anyway I am planning on improving a lot of the current shortcomings, but don’t have a final implementation plan yet.

Thanks to both of you for your great work at the edge ❤️

Yes, if you add @ToNativeInterface to your ViewModel, it should work the way you want it to, I think

ViewModel is not an interface. It is an abstract class because on Android it's a type alias to the Google ViewModel

You can still add the annotation there. It would create a kotlin interface, like ViewModelNativeProtocol and all your specific kotlin ViewModels annotated with ToNativeClass would extend it. Like

ProfileViewModelNative : ViewModelNativeProtocol

(of course you can name them differently).

hmm, should @ToNativeInterface work on actual or expected declarations? • On expected I get “Expected interface ‘ViewModelNativeProtocol’ has no actual declaration in module <…> for Native” • Same if expected and actual are annotated. • Annotating only actual in iosMain seems to do nothing

Oh, I think you found something I missed. In the annotation processor I don't analyze the expect / actual modifiers of the class. My intuition here is that koru annotations should be used on common code and generate ios source sets, so when dealing with expect/actual classes and interfaces, the generated type should not be

expect

but it probably is now and it's an error. Would you be so kind and add an issue on github with your case? I think I know what the deal is but the more details the better

@uli I figured you meant something similar to kampkit shared viewmodels so I created a similar example with koru. And released 0.12.0 which handles it. If you had time to take a look, your comment would be appreciated

Thanks, great! I am on holidays. I'll get back to you later