https://kotlinlang.org logo
Join Slack
Powered by
How has everyone's experience been with Multiplatf...
# multiplatform
a
How has everyone's experience been with Multiplatform? is it similar to a native experience for users?
m
Certainly better than writing any C/C++ code 😄 (edit: sorry missed the "for users" part, then +1 to comment below, you can make it as close to native as you want)
c
All a user will see is the UI, so if you’re still using the native UI on iOS (SwiftUI or UIKit), end-users should have no reason to suspect there’s any cross-platform code in the app at all.
p
I love it 🤩 Notice: Nothing in the stores yet, all in my development environment 🙂
a
Can someone share an example with me? Happy to install TestFlight
Esp for iOS
p
Are you talking about KMM+compose-multiplatform or just KMM? For just KMM check this examples: https://github.com/JetBrains/compose-jb/tree/master/examples For KMM+compose-multiplatform: https://github.com/JetBrains/compose-jb/tree/master/experimental%2Fexamples This is my KMP testing project, I use it to help with report bugs and also test features and profit from it in a future too https://github.com/pablichjenkov/templato
m
a
thank you so much 🙌
a
on desktop I think the startup time of the application is of particular concern for me right now
I think it's probably because it relies on the JVM there. Maybe if we get compose multiplatform for native on that target at some point that could be solved?
when it works, the developer experience is actually pretty great. expect/actual and source sets all are conceptually really nice. But I still often have issues with the KMP plugin, and gradle and what not. It's gotten wwaayy better than it used to be though.
c
For CLI apps, I can understand the frustration of JVM startup time, but in my experience, CfD apps don’t start noticeably slower than any other desktop apps I use regularly. In fact, most of the desktop app I use are based on Electron, and CfD seems to startup considerably faster than those.
a
the one where it really stands out for me is Fleet VS Vscode
m
JVM starts in ~30ms on my macbook pro. The long start times are frameworks and what not
a
if I'm just opening a text file for something really quick, VSCode is open in, idk, never timed it, but very nearly instantly. And that IS something like eletron. Fleet on the other hand takes a noticeable amount of time
oh thats interesting, maybe its frameworks, ya idk
c
Yeah, almost certainly the longer startup time is what the app chooses to do upon initialization, not the framework itself. And when comparing Fleet/IntelliJ vs VSCode, you’re comparing apples and oranges because they both have very different philosophies for how they were built and how they operate. Fleet/IntelliJ are full-blown IDEs, and are optimized for the use-case where you live in the IDE all day without closing it. It’s optimized for features, not for being lightweight. VSCode is first and foremost a lightweight text editor, that can grow into something more like an IDE experience with the plugins you choose to install. It’s optimized for that lightweight editing though, and so is likely choosing to omit features and delay initialization so that it can get you editing text as fast as possible.
Also worth noting, Fleet was not built with CfD, as it did not exist when JB started working on Fleet. It’s based upon the same tech stack as CfD (JVM, AWT, Skiko), but is not actually the same thing. IMO, they should cut their losses and migrate the UI to Compose (or at least support first-class Compose Desktop plugins), but that’s another matter entirely…
a
yeah fair enough about them being very different
b
Thought I heard somewhere that fleet client was built on rust. Or was it the backend that used rust?
o
Fleet has some parts implemented in Rust. Most of it is Kotlin.
31 Views
Open in Slack
PreviousNext
Powered by