https://kotlinlang.org logo
Join Slack
Powered by
This may well be a stupid question, but is there a...
# multiplatform
g
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.
👍 1
n
They keyword is cross platform vs multi platform. Kotlin Multiplatform is NOT trying to be a cross platform solution like React Native.
g
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.
n
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
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 =/
n
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
@Nick Halase Ahh that Moko widget thing is essentially what I was hoping for. Super neat, hopefully it or something similar picks up traction 👍
b
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 😁
d
Hmm but then your common tests are insufficient to guarantee correctness
Unless you can run common tests on every platform?
b
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
n
To add to that: It would be unreliable to test common code without executing it on each target platform.
b
Common misconception
d
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
Correct. Although "expensive" is questionable. Open source repos do it for free with GitHub actions or azure
c
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
d
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
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
k
“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
👆 1
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
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
d
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
k
What’s “everything”?
“but everything needing both a JS and a Native implementation wound up making it too big an undertaking.”
d
Anything that required interaction with the outside world.
k
What was the expectation?
d
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
k
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.
d
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
c
Another technology might fit your use-case better, perhaps 
pkg
? https://github.com/zeit/pkg
k
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.
d
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
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
d
So the common functionality is orchestrating all the external ops, but the external ops still have to be implemented one at a time.
c
Correct
d
And as I'm seeing, my use case is not the ideal use case for mpp
k
If you are doing a lot of native mapping on an uncommon use case, maybe not. Depends what you’re doing
d
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.
k
Yes
d
My head is still in "kotlin-for-things-that-are-not-mobile" land
we outsource all our mobile 😆
k
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…)
d
Well that'll work for my shop just as soon as Kotlin/Python comes out 🧌
r
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
d
Oh I'd be run out of town on a rail
But yeah I did see that
m
@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.
👍 1
v
@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.
6 Views
Open in Slack
PreviousNext
Powered by