Hey guys, remember Koru - library which generates ...

# multiplatform

[Michal Klimczak]

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

[uli]

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?

[Michal Klimczak]

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.

[uli]

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.

[Michal Klimczak]

Sure, any feedback after you try is appreciated

[Rick Clephas]

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.

[uli]

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

[uli]

Hi, I am back and ported my code to Koru for a test ride. Here are my findings:
• Koru generates wrapper classes, KMP-NC generates ‘wrapper’-methods on your own classes.
◦ This is “a good thing”. After you have instantiated your Koru generated class you can not exidentially use the original suspend function.
◦ But also causes issues if you use factoy methods on kotlin side to instantiate your objects. then you need a separate factory to produce the ios objects.
• I have a complex use case where I have view models class MyViewModelXy: ViewModel which have Koru generated native wrappers MyViewModelXyNative . Now on Swift side I need all those view models to conform to a protocol which i solve by extension (extension ViewModel: Terminable {}) but it looks like the generated classes do not inherit ViewModel. This might be a fixable implementation detail or just a missing annotation on my side. but certainly no issue with KMP-NC because it doesnot touch class hierarchies.

[Michal Klimczak]

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

[Michal Klimczak]

When it comes to the factories, yes, the idea is that android will use suspend functions and flows, and ios will have separate classes exposing suspendwrappers and FlowWrappers. That way the responsibilities are separated, although as you observed, it requires an extra step

[uli]

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

[Michal Klimczak]

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).

[uli]

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

[Michal Klimczak]

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]

https://github.com/FutureMind/koru/issues/49

[Michal Klimczak]

@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

[uli]

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