Hacker News Reader

Comment by andrekandre | Hacker News Reader

  > What KMP (and I'm hoping Swift for Android) bring is the possibility to share a Kotlin (respectively Swift) library instead of sharing code with C/C++/Rust/Go. So that an Android/iOS team can keep using Android/Swift without having to introduce a third language for sharing logic.

have gone down this route before, and tbh the biggest issue is dev ux (ios devs cant debug easily, model mismatches vs kotlin e.g kotlin exceptions cant be caught from swift) and in the end even kotlin multi platform isn't the same as kotlin for android, so in a sense you are still introducing a 3rd language after a fashion...

if you can fix the dev issues and have a dedicated team behind the shared logic it could work out, but still then again if you also have a website your re-implementing that logic on the front-end twice...

View on HN

> e.g kotlin exceptions cant be caught from swift

FWIW the approach that swift-java takes in managing interop with Java (and potentially Kotlin) function calls means it is perfectly possible to to catch exceptions thrown by the JVM using wrappers that catch and rethrow them as Swift errors. So there would be a distinction here with bringing Swift calling into JVM-based code running on Android.

  > catch and rethrow them as Swift errors

yes, in fact we implemented some wrappers for that which was done using custom annotations from the kotlin side, though if you forgot to apply it, an exception would crash our ios app… which was unfortunately not the greatest experience for ios users (who were the majority of our customers anyways)

Sure. I guess my point was that maybe your devs are more comfortable doing it in Kotlin than in C/C++/Rust.

And IMO not everything should be shared; it's worth sharing complex logic because the overhead of sharing beats the overhead of writing it twice. But in many situations it is not slower to write it twice. And I am an advocate of writing the UI on each platform to have a truly native experience for the users.

> if you also have a website your re-implementing that logic on the front-end twice...

Which argues for react-native, warts and all.

Until Static Hermes gets here it seems like a big performance loss to move to React Native.

I’ve experienced much the same as you but that’s one of the reasons I’m interested to see where Swift on Android goes. These problems are solvable, it’s just that current implementations haven’t solved them satisfactorily.

Reply on news.ycombinator.com