| I've been using Kotlin Multiplatform Mobile (KMM) heavily for the past 2 years on my current YC startup. I'm in the process of removing the entire thing. KMM is an alternative to cross platform mobile libraries like Flutter, React Native, etc. The idea is that we could write all of our mobile app's business logic, networking layer, and caching layer in Kotlin, and KMM will codgen the matching iOS code. "We only need to write it once!" is the selling point. Then we get a blank canvas to build our UI using 100% native SwiftUI & Jetpack. In reality, the codegened iOS code gets you 90% of the way there, the but extra 10% is extremely frustrating to work with. Enums (Sealed Classes in Kotlin) get mangled in translation and you lose exhaustive switch statements. Basic data types like Bool and Int get wrapped so you can only access them using additional .boolValue or Int64(..) constructors. Entire companies are being built around solving the pain point of this last 10%: https://touchlab.co In my opinion, the fatal mistake the KMM team made was designing it to support Objective-C, instead of just Swift. So you're using a Kotlin layer -> mangled through Objective-C -> accessed from Swift. It's a confusing decision, as the only iOS teams still actively using Objective-C are legacy apps (like the Twitter app), which seems like the opposite target market for new mobile tech like KMM. Kotlin and Swift are both modern languages, and my gut says the interop between the two would be much better without Objective-C in the middle. Further discussion from Droidcon if you're interested: https://www.droidcon.com/2022/08/01/sdk-design-and-publishin... > As you progress beyond "POC" to integrating and shipping real production code, the design of the "SDK surface" becomes more complicated and nuanced (or, possibly, problematic)... An Android consumer can see all the richness of the Kotlin language, but the iOS side gets filtered through Objctive-C into Swift. Much can get lost along the way. P.S. I'm replacing KMM with the Apollo Kotlin and Apollo iOS SDKs, which codegen your app's entire networking/caching layers. So it solves the same pain point (aside from business logic), but in a much cleaner way! |
One of the things that’s made solutions like this unappealing to me is how if you include networking in the shared code, you’re forgoing a bunch of platform optimizations on iOS that do things like coalesce requests to occur when the cell antenna is awake and transparently manage multi-connection situations. While it wouldn’t be too much of a problem in a simple one-note sort of app, for a more serious app that made a lot of network calls the impact is significant.