Kotlin multiplatform is stable and production-ready

Thanks for the explanation.

Unfortunately, this is far from being an isolated case. Very far.

I used to play a game on Product Hunt where I'd open multiple links without reading the description on PH, and use the homepages to try to guess what each app does.

Most of the time, it simply isn't possible. It was so frustrating that I stopped playing after awhile.

Usually people who know the word "Kotlin" at all (in a non-geographical sense) have an idea that it's a programming language and that it's normally run on JVM. They also are unlikely to miss the idea the JVM is a virtual machine, and that Android runs a kind of JVM, too. Kotlin is highly prominent in Android development, endorsed by Google for many years.

Now, I open the OP link and read: "an open-source technology built by JetBrains that allows developers to share code across platforms". I think in the context this reads pretty obviously: now you can run Kotlin code on multiple platforms. The post dives into technicalities that are geared towards people who already know enough about Kotlin, and about efforts to run it natively on different platforms.

But if you don't have that knowledge, you click https://www.jetbrains.com/kotlin-multiplatform/ (as you correctly did), and it reads, right above the fold:

"Kotlin Multiplatform allows you to create applications for various platforms and efficiently reuse code across them while retaining the benefits of native programming. Your multiplatform applications will work on different operating systems, such as iOS, Android, macOS, Windows, Linux, and others."

Maybe if you're completely alien to programming you will need more explanations. But then you're not a target audience of a blog post about a new release of Kotlin Multiplatform, much like you won't be the target audience of release notes about new features in Logic Pro if you're not a musician using it, and need explaining what "MIDI" is. And, to my mind, it's completely fine to go and find such explanations and expand your knowledge.

Either the post has been updated, or the URL has changed, because I see this in the opening paragraph:

"Kotlin Multiplatform (is) an open-source technology built by JetBrains that allows developers to share code across platforms while retaining the benefits of native programming"

Been using it for a while now in production, both for mobile apps, SDK's and some critical parts of codebase. While it works great, there are some caveats and additional tooling you need for iOS (i.e. if you want to get the pattern matching for sealed classes as enums, you need external tooling). There was some issues with coroutines, but IIRC also solved recently. For tooling, you can use IntelliJ or anything else you prefer, since you don't need all the "Android studio stuffing" until you go directly into Android development. It's just Kotlin + gradle build system.

The best thing is Kotlin - a powerful language with great syntax sugar, allowing you to write readable and performant code. Even tho at core it's a JVM language, it is compiled directly into the native language of the platform instead of providing you with a "wrapped JVM". To interact with "native" code, you only write an interface in common code and then implement the actual interfaces in the platform code, allowing you to share the contract across platforms but delegate the details.

To allow for running on other platforms, some tradeoffs are made (including the kotlin stdlib which blows up the size among some), but the saved time you get from having only one codebase shared as a library among multiple platforms is insane.

The language itself is quite mature, super comfortable to write and missing only two things: Actors, Macros and Unions. Traits would be nice too, okay. Async/await is miles ahead of whatever state the Rust is in currently.

Nowadays, my new project choice is: "do I go with Rust or do I go with Kotlin?", esp since now with WASM I can treat Rust as if it was multiplatform (Still, Kotlin is now adding WASM support and recently added WASI). But the maturity, flexibility and tooling usually make the dice fall on Kotlin.

I have used this in production for both Java and Web targets for a Startup. It did what it was promising although at earlier stage it took some research to make it work and had to adapt to changes. Now the multiplatform SDK is stable and way better documented. The Kotlin Slack community is also quite helpful for whenever you are stuck.

Using it in production for an SDK. It's working very well!

At my last company, we tried using it in production, and shipped for over a year from it. The biggest issue we ran into is that you don't find many iOS/Swift devs who like using it - the company is now swapping off KMP back to Swift for iOS.

> The constant ritual of writing the same thing twice for 2 mobile platforms must have wasted more developer hours than anything I can really think of.

probably the only thing that wasted even more developer hours was trying to get the same thing to run on two different mobile platforms.

I didn’t realize Compose could now target iOS! That’s exciting. I haven’t written Kotlin or used Jetpack Compose since the before the latter’s 1.0 release but I was very impressed at the time. Kotlin in particular stood out as an expressive, powerful, fun language. Compose had some rough edges but I picked it up, new to Android and Kotlin, and was productive very quickly. I’ll certainly consider Compose Multiplatform next time I have the need.

But why would I want the risk of your environment interacting funny with my app when I can have a known environment (electron I'm assuming) with known characteristics?

Now that even Microsoft distributes their new apps like this… I fear we lost this war. 32GB of RAM will soon be the minimum for people who run multiple apps at the same time.

Since Jetbrains their main business is selling Desktop apps (IDEs) and they are the main developer, I have high hopes.

The latter. You write your shared libraries in Kotlin, compile it for multiple runtime targets, then call your Kotlin code from whatever runtime you're using.

Write your business logic in Kotlin with Kotlin libraries.

Write your UI in Js/Android/iOS.

You can work in whatever way makes sense for you to share code.

Kotlin allows you to call native code (JS/C/ObjC/Java/WASM) from Kotlin, or you can call Kotlin functions from native code (JS/C/ObjC/Java/WASM). So you choose on what level you want to create shared code.

So it is quite flexible so it is up to you on what level you want to share code. It can either be a low level library, a middle level library. And with maturing Jetpack Compose it is possible to build the whole app including UI multiplatform without leaving Kotlin.

If you don’t mind my asking, did the networking bits hook up to native OS facilities or was that also custom (e.g. OkHttp in place of iOS URLSession)?

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.

exact same situation here

> I'm replacing KMM with the Apollo Kotlin and Apollo iOS SDKs, which codegen which codegen your app's entire networking/caching layers

interesting, in my situation we are replacing it with open-api + codegen for those parts, any good reasons to go for apollo kotlin instead?

> probably because a lot of mobile companies are happy to deal with non native Flutter/React trade offs.

Most mobile companies I know do native Android/iOS development instead of using cross-platform frameworks.

> Build and runtime performance improvements

> - Gradle configuration cache support speeds up the build process by reusing the results of the configuration phase for subsequent builds.

Any idea why configuration is so slow that it benefits greatly from caching? Is Gradle really that slow? Or is this for very complex configurations that requires probing everything about the platform, in which case I suppose there's no cross-platform development.

Kotlin Multiplatform allows you to work fully native on Android as Kotlin is the main language there. And it also allows to compile to native iOS code and integrate with native iOS Objective-C code or bridge code. (Swift integration is on the roadmap) It also allows you to directly call C code or C libraries. Or it allows to compile to JS and call JS code. So it is more versatile than Flutter and easier to integrate with native code/components. Flutter is more creating its own world with the Dart sandbox and then has to pass messages to communicate with the native world. Kotlin is closer to native output.

Jetpack Compose is the UI library and provides a similar mechanic as React/SwiftUI/Flutter in building declarative UIs. It is already the Android default as Google started to develop this UI library and Jetpacks brought in the multiplatform implementation.

Kotlin Multiplatform gives the mechanics to compile code to different platforms/targets. So it can compile code to Android, native iOS/linux/windows, web, beta web assembly, java runtimes and more.

Compose Multiplatform is the Flutter equivalent. They work on a UI toolkit which compiles to desktop/mobile/web. It works with declarative patterns like Flutter/SwiftUI/React, so is a quite modern implementation to build UIs. So it is possible to build desktop apps. Jetbrains have build their toolbox app as first desktop app since a few years using Compose. It provides many UI elements to build Desktop apps and as Jetbrains itself is a big Desktop app developer, you can expect they put their expertise into it to make it as good as possible.

Object lifetime semantics differ, forcing devs to think about non-native considerations on both Android and iOS. For a lot of CRUD apps the savings is minimal for networking / logic layers.