5 ms·

Is anyone using this in production? I played around with it a year or two ago, and it was a little rough. I recently built something internal using Rust and Uni

by jamil7 3y ago

Is anyone using this in production? I played around with it a year or two ago, and it was a little rough. I recently built something internal using Rust and UniFFI for a similar purpose. I much prefer Rust's tooling, but it would be nice to not introduce a third language. There is probably a more minimal environment I can use and not need Android Studio installed, but I'm not that familiar with Kotlin or Android development (Swift/iOS/mac day job).

thecupisblue 3y ago
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.
jurmous 3y ago
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.
mikeholler 3y ago
Using it in production for an SDK. It's working very well!
avree 3y ago
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.

by jamil7 3y ago

thecupisblue 3y ago

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.

jurmous 3y ago

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.

mikeholler 3y ago

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

avree 3y ago

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.