Thread
#multiplatform
    Antonio Acuña Prieto

    Antonio Acuña Prieto

    10 months ago
    Is KMM production ready?
    Paul Woitaschek

    Paul Woitaschek

    10 months ago
    We are using it a lot and in production. If it's production ready depends on you and your willingness to debug issues
    kpgalligan

    kpgalligan

    10 months ago
    "Production ready" comes up a lot. It's presented like a binary, but it's not a binary situation. People are putting it into production. I would say all I do is work with companies putting it into production. As Paul mentions, though, you will like spend some time sorting out config issues, etc.
    Will Shelor

    Will Shelor

    10 months ago
    we are using it in production. The code it produces is very production ready! The build system is a big challenge, though. If you can wrangle it and get the build system to work for you, the code it produces saves us a lot of time. I’d recommend having a Gradle master on your team before making the plunge, though!
    And having some cross platform senior+ engineers helps, too. Learning the limitations of the iOS side can help write Kotlin code that is also good iOS code.
    (or at least, not bad iOS code)
    Paul Woitaschek

    Paul Woitaschek

    10 months ago
    I’d recommend having a Gradle master
    Thanks to KMM I kind of became one 😁
    Learning the limitations of the iOS side can help write Kotlin code that is also good iOS code.
    And there are many things you'll just find out after some time. I've set up a guideline on what works and what not. • Many things are big questions like. How can I transform from a flow to a publisher? • What strategy do we have to marry the reactive code that android devs write with the imperative code the iOS devs write? • Which layers do we move to shared and which don't we? • How do we expose our shared lib to iOS and Android? • [...] And then there are many many smaller things to know. For example: • in Swift every object has a "description" which is equivalent to kotlins toString. We've put a description in data classes many times and that leads to a
    _description
    being exposed to iOS which is confusing. • Inline classes export as their backing property • [...] We found a solution to every problem so far and the journey was well worth it. Especially my teams got really close together in the process. Before our project with the internal code name "MobileShared" came into live, android and iOS were basically separate islands. Now we all meet regularly together and more work as one unified team.
    hfhbd

    hfhbd

    10 months ago
    @Paul Woitaschek Do you also convert a
    Flow
    into a
    Binding/State
    ? My converter works only half the time, because there is no backpressure, with results into update the UI too often. Current workaround is transforming it to a publisher and use
    receiveOn
    in the Swift view, which updates the state. But this requires a seconds state...
    Paul Woitaschek

    Paul Woitaschek

    10 months ago
    @hfhbd how does your converter work? Do you use sth like the Moko one?
    hfhbd

    hfhbd

    10 months ago
    @Paul Woitaschek Nope, I simple use this code...
    swift
    extension Binding {
        init(_ flow: MutableStateFlow) {
            self.init(get: {
                flow.value as! Value
            }) { newValue in
                flow.setValue(newValue)
            }
        }
    }
    Paul Woitaschek

    Paul Woitaschek

    10 months ago
    Ah that's not reactive but solely used as a property?
    hfhbd

    hfhbd

    10 months ago
    Yes, this is the problem! For some strange reasons it works nice with iOS 14, but fails after updating to iOS 15, because Apple changed something in SwiftUI.
    Paul Woitaschek

    Paul Woitaschek

    10 months ago
    we have an implementation similar to https://github.com/icerockdev/moko-kswift