Kotlin multiplatform is stable and production-ready(blog.jetbrains.com)
blog.jetbrains.com
Kotlin multiplatform is stable and production-ready
https://blog.jetbrains.com/kotlin/2023/11/kotlin-multiplatform-stable/
70 comments
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.
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.
>I think in the context this reads pretty obviously: now you can run Kotlin code on multiple platforms.
We always could run it "on multiple platforms", it runs on the JVM. So that's not interesting or new information that's specific to Kotlin Multiplatform.
>Maybe if you're completely alien to programming you will need more explanations.
To return your condescending tone, maybe if you're completely alien to technical information below corporate brochure level you don't need anything more specific.
(I've been doing programming for decades, so that's not it)
"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."
If you're happy with that, sure.
So, yeah, if you don't intend to do any programming in the domain it's supposedly aimed at, and have absolutely no use for it, then the information is plenty ("Kotlin for cross-platform iOS, Android, macOS, Windows, Linux programming").
For precisely the people that might be interested in it, it falls flat. Like: Do they compile your code to native? Do they just give you some native libs you can call and the ability to hook up native stuff? Can I call Swift or Android libs? Does it work with any Java library you might want to use, or are you limited to using a smaller number of Kotlin Multiplatform compatible libs? Do they have support for calling into platform APIs? If so, is it smallest common subset support, or is there support for stuff like iOS only APIs? Are perhaps some features like reflection not supported?
We always could run it "on multiple platforms", it runs on the JVM. So that's not interesting or new information that's specific to Kotlin Multiplatform.
>Maybe if you're completely alien to programming you will need more explanations.
To return your condescending tone, maybe if you're completely alien to technical information below corporate brochure level you don't need anything more specific.
(I've been doing programming for decades, so that's not it)
"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."
If you're happy with that, sure.
So, yeah, if you don't intend to do any programming in the domain it's supposedly aimed at, and have absolutely no use for it, then the information is plenty ("Kotlin for cross-platform iOS, Android, macOS, Windows, Linux programming").
For precisely the people that might be interested in it, it falls flat. Like: Do they compile your code to native? Do they just give you some native libs you can call and the ability to hook up native stuff? Can I call Swift or Android libs? Does it work with any Java library you might want to use, or are you limited to using a smaller number of Kotlin Multiplatform compatible libs? Do they have support for calling into platform APIs? If so, is it smallest common subset support, or is there support for stuff like iOS only APIs? Are perhaps some features like reflection not supported?
[deleted]
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"
"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"
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.
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.
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).
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.
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.
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.
Using it in production for an SDK. It's working very well!
Good to hear - though I've seen this being deployed a few times now and it seems to have been mature enough for a while.
Has anyone really had a chance to use Compose Multiplatform on iOS? I've love to get an an opinion on what "Alpha" really means in this case
Most of the projects I've been working on have been about playing it safe by sticking to React Native or MAUI/Xamarin - but they're both kind of getting a little bit behind with Swift UI and Compose now.
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.
Has anyone really had a chance to use Compose Multiplatform on iOS? I've love to get an an opinion on what "Alpha" really means in this case
Most of the projects I've been working on have been about playing it safe by sticking to React Native or MAUI/Xamarin - but they're both kind of getting a little bit behind with Swift UI and Compose now.
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.
> 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.
probably the only thing that wasted even more developer hours was trying to get the same thing to run on two different mobile platforms.
Damn it! I wanted to say that, but you were faster :-)
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.
I am really hoping that this kind of projects will get popular and give an incentive to write actual Desktop apps that are thought as Desktop apps instead of bundling a webapp into a browser and shipping them together.
Since Jetbrains their main business is selling Desktop apps (IDEs) and they are the main developer, I have high hopes.
Intelij might be a chonky boi, but it was one of the first apps I could point to and say 'see? java on the desktop doesn't have to suck'. I wonder what ui lib they use.
[deleted]
AFAIK they use Swing.
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.
This would still be an improvement over running apps in Electron.
I still have hopes. Android is still strong, Java/JVM is still strong for many servers, GraalVM seems very promising and JetBrains rocks.
From my Android experience, Compose is really really cool (it's similar to Flutter and I believe SwiftUI, I guess that's just the modern way). If that worked well on Desktop... I think it would be great.
I don't want a cross-platform UI framework, because Desktop is IMO fundamentally different from Mobile (e.g. mouse vs touch, big screen vs small screen, ...). But sharing libraries seems to make sense. Then from those one builds separate Desktop and Mobile apps of course.
From my Android experience, Compose is really really cool (it's similar to Flutter and I believe SwiftUI, I guess that's just the modern way). If that worked well on Desktop... I think it would be great.
I don't want a cross-platform UI framework, because Desktop is IMO fundamentally different from Mobile (e.g. mouse vs touch, big screen vs small screen, ...). But sharing libraries seems to make sense. Then from those one builds separate Desktop and Mobile apps of course.
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?
Java Swing Desktop applications solved that problem 20 years ago.
Windows 11 has compatibility that enables it to run applications written 15 years ago using, say, .NET framework 3.5 and Windows Forms. Those even work on Linux with Wine, providing a more stable ABI for programming Linux desktop apps than anything that's native to the Linux world. Wine for macOS might even bring these apps to macOS too in the future. -- So, despite the fact that those developers 15 years ago were testing on Windows XP and didn't know what my environment would look like in 2023, or that I might not even be running Windows, those applications just work.
And the libraries of UI components available through these tech stacks make Compose for Desktop look like a laughable toy.
It was only the generations of technology that came after that had persistent compatiblity problems and made you shoot for a constantly moving target. ...all we need is to get back something we've lost, which doesn't seem like such an impossible proposition at all, at least on the engineering front. Whether there's a business-will just because there's an engineering-way is a whole other question, though.
Windows 11 has compatibility that enables it to run applications written 15 years ago using, say, .NET framework 3.5 and Windows Forms. Those even work on Linux with Wine, providing a more stable ABI for programming Linux desktop apps than anything that's native to the Linux world. Wine for macOS might even bring these apps to macOS too in the future. -- So, despite the fact that those developers 15 years ago were testing on Windows XP and didn't know what my environment would look like in 2023, or that I might not even be running Windows, those applications just work.
And the libraries of UI components available through these tech stacks make Compose for Desktop look like a laughable toy.
It was only the generations of technology that came after that had persistent compatiblity problems and made you shoot for a constantly moving target. ...all we need is to get back something we've lost, which doesn't seem like such an impossible proposition at all, at least on the engineering front. Whether there's a business-will just because there's an engineering-way is a whole other question, though.
I never used Swing. Is it much better than Compose for Desktop?
There are a lot more controls, and with JavaFX (the next generation of Java UI technology that JetBrains' own IDEs are also based on), you have even more controls (and more powerful ones). Also, those controls are actually the kinds of controls that will get you the most out of using a desktop, rather than this mobile-first stuff, where the limitations of mobile platforms are the defining constraints and they needlessly constrain also what you can do with those toolkits on desktop.
Conversely, I’ve had to kill -9 some Electron-based apps lately because their myriad of helper processes were hung. It is substantially easier to debug these issues when you don’t have an entire browser engine gunking up your crash reports.
Between that, the RAM requirements, and the overall sluggishness of Electron-based apps, I’m not impressed. They’ve had what, a decade now to get their house in order?
It’s Java on the desktop all over again. Except now there’s a hegemony demanding that all dev be as cheap and shoddy as possible, so everyone just shrugs and moves along.
Between that, the RAM requirements, and the overall sluggishness of Electron-based apps, I’m not impressed. They’ve had what, a decade now to get their house in order?
It’s Java on the desktop all over again. Except now there’s a hegemony demanding that all dev be as cheap and shoddy as possible, so everyone just shrugs and moves along.
> It’s Java on the desktop all over again.
What was the problem with Java on the desktop? Maybe I was a bit too young to remember. I just remember that Java apps looked "funny".
But in my experience with the JetBrains apps in the last 8 years... JVM rocks.
I hate ElectronJS though.
What was the problem with Java on the desktop? Maybe I was a bit too young to remember. I just remember that Java apps looked "funny".
But in my experience with the JetBrains apps in the last 8 years... JVM rocks.
I hate ElectronJS though.
Java desktop apps looked and felt off, because all the windowing toolkits had to reinvent the [windowing] universe from scratch. Cold boots of apps could be painful, as the JVM didn't optimize for that, and actually deploying the apps was not pleasant (fun times guessing how much RAM the app should take as part of the CLI args).
Nowadays I have few issues with JVM apps on the desktop other than non-native UI, but that ship sailed a long time ago. And yes, JetBrains is a great example of how to do this well.
Nowadays I have few issues with JVM apps on the desktop other than non-native UI, but that ship sailed a long time ago. And yes, JetBrains is a great example of how to do this well.
Computers were much slower than today and even JVM was slower. Java wasn't open source. Plus the non-native UI made Java on desktop a meh experience.
What would really be interesting to me would be something with a featureset similar to JavaFX, but with a more up-to-date tech stack.
But it doesn't look like they're trying to take on that particular task. The compose multiplatform stuff all looks very mobile-first, with desktop a mere afterthought. The components seem like a toy subset of what JavaFX is capable of.
It's absolutely crazy, especially if you're not on mac, that you have a choice between JavaFX with an emulated UI and an outdated tech stack, Windows Forms with an insanely outdated tech stack, and everying that Microsoft did after that which lead up to WinUI 3 which comes with a crazy level of instability and a ghosttown of a developer ecosystem.
But it doesn't look like they're trying to take on that particular task. The compose multiplatform stuff all looks very mobile-first, with desktop a mere afterthought. The components seem like a toy subset of what JavaFX is capable of.
It's absolutely crazy, especially if you're not on mac, that you have a choice between JavaFX with an emulated UI and an outdated tech stack, Windows Forms with an insanely outdated tech stack, and everying that Microsoft did after that which lead up to WinUI 3 which comes with a crazy level of instability and a ghosttown of a developer ecosystem.
I have a bit trouble understanding what this is. Does it mean that I have to write my whole webapp or mobile-app in a Kotlin framework for it to give value? Or can I take some of my Kotlin libraries and convert so they're callable from js so I don't have to duplicate certain logic?
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.
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.
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.
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!
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!
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.
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.
We picked Kotlin libraries that supported KMM. So we used Apollo Kotlin, and our network requests were handled by that library's KMM translation. So there was a layer of abstraction we accepted. We never wrote raw `HttpURLConnection` code on the Kotlin side, so I'm honestly not sure what that would get translated into. KMM compiles your code into an iOS framework, so you don't actually get to see the code it creates for you (you get access to the Objective-C headers).
You're totally right, you're at the mercy of these KMM libraries and their knowledge of platform specific optimizations.
You're totally right, you're at the mercy of these KMM libraries and their knowledge of platform specific optimizations.
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?
> 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?
I just already had a graphql backend, which uses the gql schema to codegen the networking layer.
Probably not much different from an open-api schema + codegen, I just had it set up so it was an easy choice for me shrug
Probably not much different from an open-api schema + codegen, I just had it set up so it was an easy choice for me shrug
Have you tried https://tailcall.run/
It's a fairly powerful and performance focussed solution to building GraphQL backends.
got it, thanks for the info!
I’ve seen this used in a number of mobile shops when they need/want native frontends and to want share business logic, db use, networking etc. (My only gripe is that Kotlin more or less forces you to use IJ and gradle but most are happy with that). It’s been mature for a while now but has never seemed to get much airtime probably because a lot of mobile companies are happy to deal with non native Flutter/React trade offs.
> 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.
Most mobile companies I know do native Android/iOS development instead of using cross-platform frameworks.
I'm more wondering why this isn't more popular, at least with this crowd.
One reason could be that people have been burned a few times too many by technologies promising the world with regards to cross-platform, and then failing to deliver on their promises.
I think KMP could potentially be good enough to fly, but time will definitely tell on that.
I think KMP could potentially be good enough to fly, but time will definitely tell on that.
IMO cross-platform frameworks are "write once, debug everywhere". In my experience:
1. That's not particularly faster than writing native apps, but debugging is much more frustrating than writing native apps. So as a developer, cross-platform sucks, native dev is fun.
2. Desktop and Mobile are fundamentally different, so trying to write one app for both gives the worst of both worlds. Don't do that.
3. The "debug everywhere" part of cross-platform gets worse as the app gets more complicated. So the app is fundamentally getting more and more frustrating for the devs, which... well nobody wants.
On the other hand, sharing code (or libraries) between platforms sometimes makes sense. And being able to do that in Kotlin instead of, say, C++ (or Rust, I know) is actually cool.
1. That's not particularly faster than writing native apps, but debugging is much more frustrating than writing native apps. So as a developer, cross-platform sucks, native dev is fun.
2. Desktop and Mobile are fundamentally different, so trying to write one app for both gives the worst of both worlds. Don't do that.
3. The "debug everywhere" part of cross-platform gets worse as the app gets more complicated. So the app is fundamentally getting more and more frustrating for the devs, which... well nobody wants.
On the other hand, sharing code (or libraries) between platforms sometimes makes sense. And being able to do that in Kotlin instead of, say, C++ (or Rust, I know) is actually cool.
> 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.
> - 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.
Gradle is really kinda slow. There are no non-complex Gradle configurations outside of hello world examples either. If you have a huge project (where the small inefficiencies diminish) and working caching, it can be ok.
How does/will this compare to dart/flutter?
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.
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.
I thought dart/flutter compiled to native code, on whatever platform it was on. And I thought dart could directly call libraries via it's ffi?
I'm no expert so I'm likely wrong.
I'm no expert so I'm likely wrong.
If I am correct Flutter compiles to Dart code which compiles to Native code.
Above I was more talking about platform integration. As Flutter their own document states everything within Dart is compiled to run like its own enclosed runtime environment. It talks with the native world with messages over channels.
https://docs.flutter.dev/platform-integration/platform-chann...
Within Kotlin however it is possible to directly call the native method. So it looks like Flutter has more overhead for native communication than Kotlin.
Here for example a part of a C interop tutorial in Kotlin. You can directly work with data coming from C libraries.
https://kotlinlang.org/docs/mapping-primitive-data-types-fro...
Above I was more talking about platform integration. As Flutter their own document states everything within Dart is compiled to run like its own enclosed runtime environment. It talks with the native world with messages over channels.
https://docs.flutter.dev/platform-integration/platform-chann...
Within Kotlin however it is possible to directly call the native method. So it looks like Flutter has more overhead for native communication than Kotlin.
Here for example a part of a C interop tutorial in Kotlin. You can directly work with data coming from C libraries.
https://kotlinlang.org/docs/mapping-primitive-data-types-fro...
Flutter apps are written in dart which compiles to native code or js/wasm on web.
Dart can interop with swift/obj-C/Java/Kotlin through the use of channels.
Dart can interop with C/Rust/C++ directly through FFI[1]
[1]: https://dart.dev/guides/libraries/c-interop
Dart can interop with swift/obj-C/Java/Kotlin through the use of channels.
Dart can interop with C/Rust/C++ directly through FFI[1]
[1]: https://dart.dev/guides/libraries/c-interop
"Dart includes both a Dart VM with just-in-time (JIT) compilation and an ahead-of-time (AOT) compiler for producing machine code."
"Its web compiler translates Dart into JavaScript."
"Its web compiler translates Dart into JavaScript."
looks like a Java/kotlin version of flutter to me
the doc mentioned desktop and web a little but 98% are about android and iOS
I am more interested in cross platform desktop GUI,is this better than gtk or qt or wxwidgets? or swing?
the doc mentioned desktop and web a little but 98% are about android and iOS
I am more interested in cross platform desktop GUI,is this better than gtk or qt or wxwidgets? or swing?
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.
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.
make sense,not sure how google feels pushing both kotlin and dart at the same time at the cross platform apps front
Internal Google politics, if you go to the Android SDK site there is hardly any mention of Flutter.
Jake Wharton has several interesting takes regarding how Flutter was seen from Android team, during his time at Google.
https://codingwithtashi.medium.com/the-other-side-of-flutter...
https://twitter.com/JakeWharton/status/1421139368467632136
Jake Wharton has several interesting takes regarding how Flutter was seen from Android team, during his time at Google.
https://codingwithtashi.medium.com/the-other-side-of-flutter...
https://twitter.com/JakeWharton/status/1421139368467632136
I think the most beneficial part is the sharing of logic. With UI, I don't think using skia is the way to go like flutter.
But well done to the team and hopefully this continues to grow and see investment.
But well done to the team and hopefully this continues to grow and see investment.
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.
I hope there's a good distribution story for this with regards to the JVM runtime for desktop applications written with this. I vaguely recall having the right JVM runtime installed on my Linux machine was a huge pain (openJDK vs oracle) and having the right minimum version number.
But it has been a few years since I've had to use a Java desktop application. IntelliJ seem to have figured it out, though I think they just ship their own copy of the JVM runtime.
But it has been a few years since I've had to use a Java desktop application. IntelliJ seem to have figured it out, though I think they just ship their own copy of the JVM runtime.
[deleted]
Tauri to the rescue?
And by that I refer to the feat of writing a huge article without bothering to explain what Kotlin Multiplaform is.
"After several years of hard work by the JetBrains team, Kotlin Multiplatform reaches stable with the 1.9.20 release. This is a critical milestone for the platform and ecosystem. Kotlin Multiplatform was first announced at KotlinConf in 2017. Today, after years of work and amazing progress, Kotlin Multiplatform is stable! Along with progress on the tooling and library ecosystem, designating KMP to be stable will significantly increase adoption of the technology. Touchlab has been contributing to the KMP platform since the beginning, and some of our best work is still to come."
And so on.
From past reading, if I recall correctly it's a native version of Koltin (?) or a version targeted to mobile development for multiple mobile OSes, but can't be sure, nor about what kind of libs work with it (perhaps any?).
This helps a little:
https://www.jetbrains.com/kotlin-multiplatform/
Still, this page too could do a much better job, instead of selling "what it can do" to manager types:
"Open-source technology by JetBrains for flexible multiplatform development" / "The Kotlin Multiplatform technology is designed to simplify the development of cross-platform projects." / "Reuse code across Android, iOS, web, desktop, and server-side while keeping native code if needed"),
to plainly tell "what it is" to tech types. So, something like:
"The shared business logic code for Android gets converted to Java bytecode that can be executed in JVM and Android has the virtual machine, so it can easily run it. But in the case of iOS, there is no virtual machine, so the code is converted to the native code that can be executed on iOS. Now in the Kotlin compiler, there is a frontend that converts the code into an intermediate representation known as IR, and the backend converts that intermediate representation to machine-executable code. So in the case of android, it converts it into java bytecode, and for iOS, it converts it into iOS native machine code."
Had to go to a third party website to find this description.