TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Kotlin multiplatform is stable and production-ready

90 点作者 cvb941超过 1 年前

13 条评论

coldtea超过 1 年前
Amazing effort.<p>And by that I refer to the feat of writing a huge article without bothering to explain what Kotlin Multiplaform is.<p>&quot;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.&quot;<p>And so on.<p>From past reading, if I recall correctly it&#x27;s a native version of Koltin (?) or a version targeted to mobile development for multiple mobile OSes, but can&#x27;t be sure, nor about what kind of libs work with it (perhaps any?).<p>This helps a little:<p><a href="https:&#x2F;&#x2F;www.jetbrains.com&#x2F;kotlin-multiplatform&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.jetbrains.com&#x2F;kotlin-multiplatform&#x2F;</a><p>Still, this page too could do a much better job, instead of selling &quot;what it can do&quot; to manager types:<p>&quot;Open-source technology by JetBrains for flexible multiplatform development&quot; &#x2F; &quot;The Kotlin Multiplatform technology is designed to simplify the development of cross-platform projects.&quot; &#x2F; &quot;Reuse code across Android, iOS, web, desktop, and server-side while keeping native code if needed&quot;),<p>to plainly tell &quot;what it is&quot; to tech types. So, something like:<p>&quot;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.&quot;<p>Had to go to a third party website to find this description.
评论 #38114252 未加载
评论 #38114266 未加载
评论 #38114227 未加载
jamil7超过 1 年前
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&#x27;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&#x27;m not that familiar with Kotlin or Android development (Swift&#x2F;iOS&#x2F;mac day job).
评论 #38112357 未加载
评论 #38113248 未加载
评论 #38114115 未加载
评论 #38113453 未加载
sdflhasjd超过 1 年前
Good to hear - though I&#x27;ve seen this being deployed a few times now and it seems to have been mature enough for a while.<p>Has anyone really had a chance to use Compose Multiplatform on iOS? I&#x27;ve love to get an an opinion on what &quot;Alpha&quot; really means in this case<p>Most of the projects I&#x27;ve been working on have been about playing it safe by sticking to React Native or MAUI&#x2F;Xamarin - but they&#x27;re both kind of getting a little bit behind with Swift UI and Compose now.<p>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.
评论 #38112377 未加载
评论 #38112776 未加载
palata超过 1 年前
I am really hoping that this kind of projects will get popular and give an incentive to write <i>actual Desktop apps that are thought as Desktop apps</i> instead of bundling a webapp into a browser and shipping them together.
评论 #38112994 未加载
评论 #38112927 未加载
评论 #38112906 未加载
stakhanov超过 1 年前
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.<p>But it doesn&#x27;t look like they&#x27;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.<p>It&#x27;s absolutely crazy, especially if you&#x27;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.
matsemann超过 1 年前
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&#x27;re callable from js so I don&#x27;t have to duplicate certain logic?
评论 #38111742 未加载
评论 #38113184 未加载
评论 #38111879 未加载
joshuakcockrell超过 1 年前
I&#x27;ve been using Kotlin Multiplatform Mobile (KMM) heavily for the past 2 years on my current YC startup. I&#x27;m in the process of removing the entire thing.<p>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&#x27;s business logic, networking layer, and caching layer in Kotlin, and KMM will codgen the matching iOS code. &quot;We only need to write it once!&quot; is the selling point. Then we get a blank canvas to build our UI using 100% native SwiftUI &amp; Jetpack.<p>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%: <a href="https:&#x2F;&#x2F;touchlab.co" rel="nofollow noreferrer">https:&#x2F;&#x2F;touchlab.co</a><p>In my opinion, the fatal mistake the KMM team made was designing it to support Objective-C, instead of just Swift. So you&#x27;re using a Kotlin layer -&gt; mangled through Objective-C -&gt; accessed from Swift. It&#x27;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.<p>Further discussion from Droidcon if you&#x27;re interested: <a href="https:&#x2F;&#x2F;www.droidcon.com&#x2F;2022&#x2F;08&#x2F;01&#x2F;sdk-design-and-publishing-for-kotlin-multiplatform-mobile-2&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.droidcon.com&#x2F;2022&#x2F;08&#x2F;01&#x2F;sdk-design-and-publishin...</a><p>&gt; As you progress beyond &quot;POC&quot; to integrating and shipping real production code, the design of the &quot;SDK surface&quot; 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>P.S. I&#x27;m replacing KMM with the Apollo Kotlin and Apollo iOS SDKs, which codegen your app&#x27;s entire networking&#x2F;caching layers. So it solves the same pain point (aside from business logic), but in a much cleaner way!
评论 #38114542 未加载
评论 #38122742 未加载
tarkin2超过 1 年前
I’ve seen this used in a number of mobile shops when they need&#x2F;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&#x2F;React trade offs.
评论 #38112857 未加载
评论 #38113145 未加载
account-5超过 1 年前
How does&#x2F;will this compare to dart&#x2F;flutter?
评论 #38113087 未加载
synergy20超过 1 年前
looks like a Java&#x2F;kotlin version of flutter to me<p>the doc mentioned desktop and web a little but 98% are about android and iOS<p>I am more interested in cross platform desktop GUI,is this better than gtk or qt or wxwidgets? or swing?
评论 #38112977 未加载
monlockandkey超过 1 年前
I think the most beneficial part is the sharing of logic. With UI, I don&#x27;t think using skia is the way to go like flutter.<p>But well done to the team and hopefully this continues to grow and see investment.
评论 #38111848 未加载
lordofgibbons超过 1 年前
I hope there&#x27;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.<p>But it has been a few years since I&#x27;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.
评论 #38113830 未加载
diamondfist25超过 1 年前
Tauri to the rescue?