A modern programming language that makes developers happier.

kotlinlang

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

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

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.

&gt; I’d recommend having a Gradle master
Thanks to KMM I kind of became one :grin:

&gt; 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.

<@U0KBF8D7V> 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...

<@U01JRLZH77T> how does your converter work?
Do you use sth like the Moko one?

<@U0KBF8D7V> Nope, I simple use this code...
```swift
extension Binding {
    init(_ flow: MutableStateFlow) {
        self.init(get: {
            flow.value as! Value
        }) { newValue in
            flow.setValue(newValue)
        }
    }
}```

Ah that's not reactive but solely used as a property?

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.

we have an implementation similar to <https://github.com/icerockdev/moko-kswift>