Hacker News Reader

Comment by dickersnoodle | Hacker News Reader

iOS dev here. What you're missing is that a ton of native-code developers (me included) aren't interested in adopting an abstraction layer that has to be tweaked to approximate the look and feel of the native OS UI layer when we could just built it natively to begin with and save all that effort. We've seen PhoneGap/Cordova, we've seen React Native and we'll keep seeing money thrown away on pretending that there aren't real platform differences when there are.

View on HN

As an Android developer that's been using Compose and multiplatform I believe the play is to get Android developers to be able to minimally adapt their apps to run on iOS. They don't pretend that you don't need to know anything about iOS but are trying to abstract as much (or as little) a way to compile to both.

The other multiplatform attempts failed because they were trying to use languages that neither side wanted or knew and pretended like you could drop in a dev from a completely different field and not need to know much about the platforms. If you did know the platform you were fighting against the framework in an unfamiliar language.

That said it is definitely not there yet, but I hope they get it to a reasonable place. I've enjoyed Android development and would love to be able to more simply port over a project without a complete rewrite.

The idea is you can write SwiftUI on iOS, whilst connecting to business logic written in Kotlin.

im not a phone app dev, but im curious, cant you already write backend code in another language and the ui in swift

Business logic is not only about backend. Apps usually have a lot of client-side logic that can be written once in KMM and used on both platforms. See [1] for a high level architecture diagram.

I'm an iOS dev and I've been using KMM on a couple of projects for more than a year now. It's really a powerfull technology which allows teams to move faster, but there are downsides, for example lack of native Swift interop, though there are opensource tools trying to solve this [2].

[1]: https://github.com/Kotlin/kmm-production-sample/tree/master#... [2]: https://github.com/touchlab/SKIE

Sort of but not really. SwiftUI is reactive, with view changes triggered by changes in Swift variables and those changes triggered using Combine. The later iterations of Swift include async/await to greatly simplify async code (normally but not always focused on network endpoints). You can write everything you need without having to drag Kotlin into the mix, and including Kotlin will require bridge code that seems (to me, at least) an unwanted obligation just to let some executive say "We saved some money by sharing code!".

No no no. Just look at the janky stuff one needs to do to compile Kotlin for an iOS project. Plus, object lifetime semantics differ. Now you won’t be able to write Kotlin native code without thinking of iOS rules. So now you have the worst of unfamiliar worlds with a “most fast” product speed.

Stack traces look like garbage though. I've developed a library for KMM. The iOS devs didn't want to touch it, so write once, make android devs keep it up. Also it was the network layer, so that's the easiest shit to write natively.

This. It’s exactly the same for me (also iOS dev, and I do Swift on the server too).

Reply on news.ycombinator.com