Sadly in my multiplatform project (an app for Android and iOS), I had to ultimately forego the use of kotlin multiplatform for shared logic, because of the lack of generics conversion from Kotlin to Swift. I’ll have to be patient until it is implemented 🙂

Since ObjC is used as the bridging layer it can’t happen until ObjC has better support for generics. ObjC has support for them in Collections containers but nowhere else. It would be nice if the native stuff could interop with Swift directly but there isn’t a stable ABI for Swift yet.

So I gathered, yes. I understand that Swift generics, protocols and associated types work quite differently than other languages anyway.

I guess I’m just used to having to dumb down my Swift code to work with ObjC objects that it doesn’t bother me too much. Plus the potential savings that comes with using the same code base across platforms keeps me interested. Having worked on large teams where one group did Android and the other iOS I’ve lost track of the number of bugs that were filed because one developer interpreted the requirements differently from the other.

Yes, this has been my experience as well. I still strongly believe in kotlin multiplatform, it just quite doesn’t fit my project at the moment. Can’t wait to see things as they evolve.

I’m curious what angle you’re coming at Kotlin from. Are you primarily a Swift developer using Kotlin to do some Android development or vice versa?

I’m an Android developer with 2 years of experience in Kotlin (I’ve been using it exclusively since the alpha came out), and I have only a few days of experience with Swift and iOS. I just got a grasp of Protocol Oriented Programming and how to use PATs, and I don’t really want to give that up, even for something as great as Kotlin multiplatform, which I am super excited about 🙂

Ah. I’m coming at it from the other direction. I’ve done lots of iOS and swift. Recently picked up Kotlin to do an Android project and found myself wishing I didn’t have to write so much duplicated code. I’m missing Swift style generics though. Probably because I haven’t found good ways to work around type erasure pain points yet.

If you have not already, take a look at sealed class, they often apply as a different and better way to do something you could also do with generics. In Kotlin, you cannot achieve statically define generic extensions as you do in Swift. But you have dynamic dispatch, which is convenient but can lead to generic madness.