Hi, we wanted to adopt KMM and I had my iOS colleague doing a spike by re-writing a lib of iOS in KMM. i turned out that there is a blocker for us to use and certain flaws: • no support for

Codable

in iOS: currently nearly all models of our native iOS app implement that protocol and therefore shared KMM models cannot be used in those models (unless you manually write (de)serialization for that shared objects - which is a blocker for us) - seems like a known issue - but i wonder why there is not much more noise around that. other issues he mentioned: • Operator overloads do not translate to Swift ◦ e.g. cannot overload operators such as

+

,

-

,

<

etc. (required for conformance to

Comparable

for example) • Cannot take advantage of other protocol conformances, e.g. inheriting from the protocol

Sequence

gives a huge amount of functionality such as

map

,

flatMap

,

forEach

etc. • Integers are all represented as

Int32

in Swift - annoying to do conversions to a regular

Int

everywhere • Cannot create non-final classes, meaning we cannot implement any class as

Codable

or

Strideable

(needed to allow us to loops over calendar dates in a calendar date range) • Unable to have “Swifty” function names as it’s not possible to remove parameter names, and parameter labels have to be the same as the parameter names. i.e. we cannot have a function like

func date(in timeZone: TimeZone) -> Date

would be great if someone can confirm this limitations or provide guidance on how to overcome those.

Your swift code will need to interact with the Kotlin code as if it were written in ObjC. It’s a little different mental model than just interacting with another swift library. 1. Instead of codable use Kotlin serialization. 2. Int in swift is 64 bits on 64 bit platforms but 32 on 32 bit platforms such as earlier watch models and “ancient” iPhones like the 5. Using a Kotlin long should map it to int64 which will work with a swift Int. 3. You can write an extension in swift to a Kotlin class to add protocol conformance. No need to inherit from it. 4. Parameter and method names can be an issue. Swift and ObjC don't have namespaces so the interface has to flatten them when exporting from Kotlin. It can be overly aggressive and append underscores to your identifiers when it's not necessary. It’s not great but the benefits of code sharing never made me stop for this reason.

thanks for your reply. ad 1 (android developer speaking without much iOS background) - from what i got is that our iOS codebase is using

Codable

heavily in their Swift classes. if we now share a

Time

KMM class - every (codable) Swift Entity which uses that

Time

class would need to manually write serialization to support it beeing used as codable in the iOS world. are you suggesting to remove Codable from iOS all along?

I always end up with a matching Swift file wrapper that 'Swift-ifies' the ObjC framework created by the Kotlin MP compiler. Int32 -> Int, callbacks to Swift Result, Kotlin extensions to Swift extensions, etc. My dream would be if the tools allowed generating an SPM module with a Swift file included on the Kotlin side. This way it is an easy import to any Swift project and the wrapper comes with it...

At my team, we have a module between the “client” and KMM module, this module helps to translate or adapt some of those limitations you describe but also opens the chance to implement some logic with the platform specific frameworks. This last option should be as a “no alternatives” plan.