Thread
#multiplatform
    Christoph Wiesner

    Christoph Wiesner

    2 months ago
    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.
    s

    Sam

    2 months ago
    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.
    Christoph Wiesner

    Christoph Wiesner

    2 months ago
    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?
    tylerwilson

    tylerwilson

    2 months ago
    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...
    Alex Acosta

    Alex Acosta

    2 months ago
    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.