Kotlin Multiplatform can be used without hesitation for sharing code in production across Android, iOS, desktop (JVM), server-Side (JVM), and web, even in the most conservative usage scenarios
Bit curious what they mean by “even in the most conservative usage scenarios”.
And is this intended for sharing common library code but building platform-specific UIs, or is it that I can build a desktop and web and mobile UI all with Kotlin Multiplatform?
And is this intended for sharing common library code but building platform-specific UIs, or is it that I can build a desktop and web and mobile UI all with Kotlin Multiplatform?
The latter seems to be a goal, but not yet finished. They have a crossplatform UI library, Compose Multiplatform, but the announcement (a bit further down the page from your quote) says it’s only currently production ready for Android and JVM. The iOS support is alpha, with a beta release scheduled for 2024, while the web support is “experimental”, with an alpha scheduled for 2024.
This is the case today. Certainly how I have experienced it, common code in shared libraries for Android and iOS One further caveat is that the iOS code is an obj-c interface so some swift niceties are a little clunky.
I am very curious to see where Kotlin Multiplatform (KMP) would go in the industry.
One of the things they are doing that seems actually new is not trying to force a new multiplatform UI library. Many have tried before, and the idea always crumbles at a point where you really want iOS users to feel at home, and Android users to get familiar controls. So you start bending your “unified UI stack” backwards for each of the platforms. And it turns into mediocre UX on all of them.
KMP’s promise is that you can always keep the UI native to the platform, and just swap out the business logic (common code). And business logic is something inherent to your domain, not the platform where you distribute your app. So it actually makes sense to reusing a single implementation of that logic.
I think it is a very smart play, and a truly modern approach to the current industry situation.
Here’s what they mean by multiplatform:
Bit curious what they mean by “even in the most conservative usage scenarios”.
And is this intended for sharing common library code but building platform-specific UIs, or is it that I can build a desktop and web and mobile UI all with Kotlin Multiplatform?
The latter seems to be a goal, but not yet finished. They have a crossplatform UI library, Compose Multiplatform, but the announcement (a bit further down the page from your quote) says it’s only currently production ready for Android and JVM. The iOS support is alpha, with a beta release scheduled for 2024, while the web support is “experimental”, with an alpha scheduled for 2024.
This is the case today. Certainly how I have experienced it, common code in shared libraries for Android and iOS One further caveat is that the iOS code is an obj-c interface so some swift niceties are a little clunky.
I am very curious to see where Kotlin Multiplatform (KMP) would go in the industry.
One of the things they are doing that seems actually new is not trying to force a new multiplatform UI library. Many have tried before, and the idea always crumbles at a point where you really want iOS users to feel at home, and Android users to get familiar controls. So you start bending your “unified UI stack” backwards for each of the platforms. And it turns into mediocre UX on all of them.
KMP’s promise is that you can always keep the UI native to the platform, and just swap out the business logic (common code). And business logic is something inherent to your domain, not the platform where you distribute your app. So it actually makes sense to reusing a single implementation of that logic.
I think it is a very smart play, and a truly modern approach to the current industry situation.