Thread
#multiplatform
    g

    Gavin Ray

    2 years ago
    This may well be a stupid question, but is there any chance in the future that Kotlin might target crossplatform native mobile apps in their entirety? Essentially something like React Native/NativeScript/Flutter? I had largely dismissed Java and the JVM for my entire career because of enterprise + massive bloat, but Kotlin has made me want to give it a shot. Especially with libraries like Arrow. It seem as though you can write incredibly clean multi-paradigm code and leverage all of the existing tooling and libraries for Java & the JVM. Essentially, something on the order of a better Typescript from the looks of it. My only hangup is that I have a hard time justifying picking up Kotlin and the JVM, when I am able to write Frontend + Backend + Cross-platform mobile apps in entirely Typescript. And then the hiring + talent-finding process becomes more difficult because I have to hire JS/TS devs and Java/Kotlin devs.
    Nick Halase

    Nick Halase

    2 years ago
    They keyword is cross platform vs multi platform. Kotlin Multiplatform is NOT trying to be a cross platform solution like React Native.
    g

    Gavin Ray

    2 years ago
    Sure, I was aware of that. I did a fair amount of reading on the Kotlin MPP documentation and checked out the KaMP Kit repo. So I understand that bit, my question was more whether or not it's possible or a goal sometime in the future.
    Nick Halase

    Nick Halase

    2 years ago
    I wouldn't expect it to be. I believe it would go against the design philosophy of Kotlin Multiplatform.
    But also, I am not any sort of authority on this.
    g

    Gavin Ray

    2 years ago
    Ahh, damn. I hope some time in the future that the ability to develop a technology stack end-to-end in Kotlin becomes an option, because it seems like it has a lot to offer. From an economics and business perspective though, it's impossible to justify versus just writing everything in JS/TS and hiring JS devs =/
    Nick Halase

    Nick Halase

    2 years ago
    To me, it just doesn't seem like the responsibility of MPP. That being said, there are people building out libraries to support this use-case. See https://github.com/icerockdev/moko-widgets for example.
    Even if MPP did support UIs, MPP is far more than a solution for Android and iOS. It's also targeting wearables, Windows, Mac and Linux.
    g

    Gavin Ray

    2 years ago
    @Nick Halase Ahh that Moko widget thing is essentially what I was hoping for. Super neat, hopefully it or something similar picks up traction 👍
    Derek Berner

    Derek Berner

    2 years ago
    Maybe question for the channel but what is the perceived benefit of MPP if everything must be implemented multiple times for each platform? Just nonduplication of essential business logic and data models?
    b

    basher

    2 years ago
    You get benefit as soon as you use that platform-specific code that is expect/actual'd in common code.
    Alec and I talk about this in our KotlinConf talk 😁
    Derek Berner

    Derek Berner

    2 years ago
    Hmm but then your common tests are insufficient to guarantee correctness
    Unless you can run common tests on every platform?
    b

    basher

    2 years ago
    The only way to test is run them on every platform
    There's no common environment
    Only the env/arch of each platform you support
    Nick Halase

    Nick Halase

    2 years ago
    To add to that: It would be unreliable to test common code without executing it on each target platform.
    Common misconception
    Derek Berner

    Derek Berner

    2 years ago
    So if I have
    windows
    ,
    macos
    ,
    linux
    ,
    ios
    and
    android
    targets, there's just no way to test everything at the push of a button
    Short of an expensive CI server
    Or a complex Vagrant setup
    b

    basher

    2 years ago
    Correct. Although "expensive" is questionable. Open source repos do it for free with GitHub actions or azure
    c

    Casey Brooks

    2 years ago
    IMO, one of the bigger draws to using MPP is that it can be adopted slowly, after the start of a project. For the most part, React Native and Flutter expect you to start a new app to use them. Take existing apps and cut down on duplicated work by making new features as MPP, without needing any major overhaul of app architecture
    Derek Berner

    Derek Berner

    2 years ago
    What's the mechanism for slow adoption? I attempted to start converting a
    grunt
    script into Kotlin/JS, with the goal of eventually replacing it with a K/N executable... but everything needing both a JS and a Native implementation wound up making it too big an undertaking.
    c

    Casey Brooks

    2 years ago
    Creating a MPP library which publishes native artifacts: a jar for JVM, a Framework for iOS, NPM modules for JS. Existing projects then include those artifacts as if it were any other platform-native library
    kpgalligan

    kpgalligan

    2 years ago
    “slow adoption” as in sharing code for some functionality and not others. If you’re going to convert something from scratch, that’s not slow
    I’m also not clear on how implementing something 100% in kotlin/js is “multiplatform”. Not criticism, just not the use case for slow adoption. To answer “Just nonduplication of essential business logic and data models?” Yes. Just the data, logic, architecture, and testing of all these things.
    c

    Casey Brooks

    2 years ago
    It’s also worth mentioning that you don’t typically have to do much work to support additional platforms with the Gradle MPP plugin. If you aim for writing everything in the common sourceset using facilities from the stdlib and other pure-Kotlin libraries, then you, the library developer, likely don’t need to do much actual/expect work yourself. And the Gradle plugin will (mostly) run your common tests on all configured platforms, too; you don’t need to write dedicated tests for each platform
    Derek Berner

    Derek Berner

    2 years ago
    100% in kotlin/js
    Kotlin/js + Kotlin/native
    Not from scratch but one function at a time with the js version being available as an npm library to the original tool
    kpgalligan

    kpgalligan

    2 years ago
    What’s “everything”?
    “but everything needing both a JS and a Native implementation wound up making it too big an undertaking.”
    Derek Berner

    Derek Berner

    2 years ago
    Anything that required interaction with the outside world.
    kpgalligan

    kpgalligan

    2 years ago
    What was the expectation?
    Derek Berner

    Derek Berner

    2 years ago
    AWS especially. I have to write an interface to talk to AWS then implement it separately on native + JS as wrappers around the C and JS libs
    kpgalligan

    kpgalligan

    2 years ago
    Right
    You’d need to write a multiplatform AWS library if you wanted that to not be true, but nobody’s done that.
    Why would you eventually move that to native anyway? I guess it doesn’t matter, but seems like not a common use case.
    Derek Berner

    Derek Berner

    2 years ago
    We want something to drop in /bin on our CI servers so that our projects don't have to have NPM and include grunt in
    package.json
    to be part of our deploy ecosystem.
    Not all our projects are node
    I mean you could just as easily provide it as an executable jar
    kpgalligan

    kpgalligan

    2 years ago
    You need a KMP AWS library that would talk to both native implementations. Not hard to make, maybe, but KMP wouldn’t auto-map that.
    c

    Casey Brooks

    2 years ago
    Another technology might fit your use-case better, perhaps
    pkg
    ? https://github.com/zeit/pkg
    Derek Berner

    Derek Berner

    2 years ago
    Yeah that's where I headed before I reported that it would be too much.
    Yeah huh,
    pkg
    would do that without a rewrite.
    c

    Casey Brooks

    2 years ago
    Something to keep in mind is that MPP isn’t magic; it doesn’t enable interop among its different supported platforms. It simply provides a common platform that others can interop with. So if there’s functionality on one platforrm that you want on another, you would need to re-implement it in MPP code
    Derek Berner

    Derek Berner

    2 years ago
    So the common functionality is orchestrating all the external ops, but the external ops still have to be implemented one at a time.
    c

    Casey Brooks

    2 years ago
    Correct
    Derek Berner

    Derek Berner

    2 years ago
    And as I'm seeing, my use case is not the ideal use case for mpp
    kpgalligan

    kpgalligan

    2 years ago
    If you are doing a lot of native mapping on an uncommon use case, maybe not. Depends what you’re doing
    Derek Berner

    Derek Berner

    2 years ago
    Take existing apps and cut down on duplicated work by making new features as MPP
    So you're talking, say I have an iOS app and an Android app, I can write a new feature in MPP, include the compiled artifact in both, without a major overhaul of the architecture.
    kpgalligan

    kpgalligan

    2 years ago
    Yes
    Derek Berner

    Derek Berner

    2 years ago
    My head is still in "kotlin-for-things-that-are-not-mobile" land
    we outsource all our mobile 😆
    kpgalligan

    kpgalligan

    2 years ago
    Some teams are writing logic that is shared on front end and back end as shared code. Some doing js.
    And we do the outsourcing (not for you specifically, but…)
    Derek Berner

    Derek Berner

    2 years ago
    Well that'll work for my shop just as soon as Kotlin/Python comes out :troll:
    russhwolf

    russhwolf

    2 years ago
    I've never tried it out and I'm not aware of anyone using it for anything real, but there is a python interop sample in the Kotlin/Native samples directory https://github.com/JetBrains/kotlin-native/tree/master/samples/python_extension
    Derek Berner

    Derek Berner

    2 years ago
    Oh I'd be run out of town on a rail
    But yeah I did see that
    matej

    matej

    2 years ago
    @Casey Brooks Just wanted to clarify, React and Flutter do not expect you to start a new app. I did an evaluation of code sharing solutions for mobile for my org recently, and both of those allow you to extend an existing application by developing new features/workflows with them, and launching them as a new Activity/ViewController from your existing app. The real selling point of KMP is that, unlike React/Flutter, it's not a complete paradigm shift for an experienced native mobile developer. It's much closer to native, and if you set things up right, much of your team can be blissfully unaware that KMP even exists for quite some time, until they want to be aware and contribute to your library.
    Vladimir Mutafov

    Vladimir Mutafov

    2 years ago
    @Gavin Ray you can check out NativeScript’s 6.5.0 release: https://www.nativescript.org/blog/whats-new-in-nativescript-6-5 There is experimental support for writing apps with KotlinJS. It is still more of a PoC but there is a link to a sample app at the end of the blog post.