Hello, I did quite a bit of Google searching to t...

# kotlin-native

[James Good]

Hello,

I did quite a bit of Google searching to try to find out what the limitations of Kotlin native might be.

I know that using Java libraries is a no go, but what about for stdlib functions in kotlin which delegate to Java, such as the Random module or this module https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.concurrent/java.util.-timer/schedule.html

I see from the colored tabs on the website that it is appears to only have JVM support, but is there another option to use similar functionality as timer.schedule while using kotlin native?

[ribesg]

Kotlin Random is available on all platforms as well as Coroutines with which you can implement Java Timer like behavior

[ribesg]

In the end what you can and can’t do depends on the platform you’re targeting. Kotlin/Native allows you to write code for Windows or iOS, which are already vastly different

[James Good]

Since you mention windows or iOS I imagine you have GUI applications in mind.

I only intend to write backend/server/cli type of applications.

Using Java third party libraries isn’t much of a concern, as most stuff I'm writing won’t rely on anything aside from an http library or Arrow.

[ribesg]

Not necessarily, for example handling files is different. But now we have okio for that. I made my own files lib because okio wasn’t a thing before

You may also need to handle dates. I heard kotlinx-datetime made great progress, but back in my days I made my own multiplatform date library too. You might still have to do that for specific things but I feel like nowadays things are pretty great

[James Good]

Are you just programming for enjoyment now? Just asking because you said back in my days.

Thank you for giving me a better idea regarding the state of things.

[ribesg]

Haha no, I just started using Kotlin/Native in production WAY too early, like at the very beginning of 2019. Things were very different

[ribesg]

Doing real stuff with Kotlin/Native today is completely ok I think. Not as smooth as with older tech obviously, but still good. In 2019 it really was a bad idea. But it was fun

[James Good]

I see haha. Well it seems Kotlin as a language is likely to continue growing in the future. However, I’m unaware of the difficulties of maintaining a project such as kotlin native, and if the motivation of having an executable rather than just running on JVM will be enough to justify the continued maintenance and growth of the project.

Given your experience is since 2019, you're still here, and the project has matured even further since you started using it; that does give an indication of its future trajectory.

I’m not a mobile developer, so I'm unaware of the android and iOS multi platform kotlin usage, but is kotlin native a sort of dependency in order to make multi platform mobile app development possible?

[James Good]

After watching this part at minute 14, this seems like a sufficient reason for kotlin native to continue to be used over just the JVM running it on JVM.

Posted this before watching the part where the workarounds to maintain safety are presented.

https://youtu.be/uzjp5F22Igs▾

[ribesg]

Yeah Kotlin/Native allows much more than just running an executable instead of the JVM. I have a production iOS app written in 100% Kotlin (something like 40kloc) and it relies on dozens of Kotlin Multiplatform libraries used in other Android/iOS/JVM projects.

[James Good]

Ahh noice. What does the app do (if you don’t mind discussing that here)?

Also, did you ever consider flutter, and if so, what made you choose kotlin multiplatform over it?

I ask because I’ve never created a full mobile app, but having some reactJS experience made flutter pretty easy to jump into. Albeit, I don't know what libraries/features may be missing that would impede getting certain mobile apps into production.

[ribesg]

The app does a lot of stuff. It’s an app doing different things on iPhone and on iPad, with 3 different types of users. Basically we use it to handle job dating events. There are iPads at the entrance where candidates can scan a QRCode and consent (or not) to some legal stuff. We give iPads to recruiters on which they can see their interview planning, see the resume of candidates and take notes on interviews. Organisers have the same app on iPhone where it does a lot of things, like manually onboarding candidates, accessing all the data about candidates, recruiters, their plannings, etc. Can call them or send them texts. Overall does a lot of stuff.

I never considered learning a language just for a framework, it was stupid and still is. Also I don’t like to use the web on a smartphone as a user (it’s terribly bad), so I don’t like developing web stuff for phones. Flutter is very limited compared to native, which can work for a lot of cases, especially prototyping or making an app when you only have an army of web devs and no mobile dev. For example we need to have an app ready for both platforms in 5 months (actually more like 4 now). The app will be done in web and then maybe published to stores as a PWA. It will be much less qualitative than a carefully crafted native app, but you can’t make the same amount of features in 5 months, especially when I’m the entire mobile developers team 😄

[James Good]

Hmm, why do you say Flutter is essentially web on phone?

It's been at least two years since I’ve touched it, but I was comparing it side by side with React Native, and it isn’t really web on phone, it using a bridging concept which makes the app less performant.

While I don’t remember all of the technical details I do remember something called skia which is how flutter does it's drawing to the mobile screen, it’s essentially a canvas on which shapes can be drawn (not to be associated with the web’s canvas api).

From what I saw, animations were pretty easy to implement via the api that was exposed and if you needed some native functionality (such as Bluetooth) then you’d just write a mobile in swift or kotlin and then make a call to it from flutter (I never tried, so I can’t speak on how good/easy that interoperability is).

But I definitely hear you on not wanting to learn a language just for a framework.

While I wouldn’t rule out flutter if a need for a mobile app arises for me in the future, I'd still prefer kotlin to have only one frontend and backend.

But when you say flutter is very limited compared to native, what are you thinking of?

[ribesg]

Mobile devices generally offer much, much more complex functionalities than what a website could handle. Compared to a mobile-first website, something made with Flutter or others will be more efficient, with a more fluid UI and better animations, and can somehow access some of those unique features. You can get that with a native app too + much more, like far better access to advanced features of mobile devices (or more on Android) like AR/VR, IoT, TV, gaming, wallet/payment stuff etc., more complex UIs are generally easier in native because you have more control but also with the stupid amount of libraries available. Everything is just made to work with “standard” Android/Kotlin and/or iOS/Swift, so yeah you can make wrappers for Flutter… But why not do that with Kotlin/Multiplatform instead, it’s easier and you just use Kotlin everywhere

Of course if your mobile app is basically a glorified landing page, it doesn’t matter what you use. Flutter is good for prototyping etc. But if you don’t need to have an app ready fast, I wouldn’t recommend it

[James Good]

When you say payments, are you talking about using iOS mobile pay feature?

I may give that a shot in both KMM and flutter to get an idea of the process in both.

[ribesg]

I don't know what you can and can't use in Flutter, I just know what you can use in native. Everything. Unknowns aren't good

[James Good]

Well,I’m just taking one example that you listed above in order to see the differences in implementing it in KMM and Flutter.

This is the interop that I was talking about for flutter to native code

https://docs.flutter.dev/development/platform-integration/ios/c-interop

[James Good]

I haven’t used it before, so I don't know how easy/difficult it may be.

And me bing a neophyte to mobile dev, I figure it would at least be a good exercise to see how it works in both.

Most apps that I'd want to make right now wouldn’t really use many native features, but this still seems like something I'd be interested in testing out.

[ribesg]

Kinda looks like what you do when using an ObjC lib or iOS APIs in Kotlin

[James Good]

Perfect, then this should be a good little test

[ribesg]

But when on native most people have their app in Swift, and use both Kotlin and Swift libs from Swift

[ribesg]

I don't use multiple languages because I find it hard to switch between languages when switching task, so I do 100% Kotlin, but it's still uncommon

[ribesg]

You shouldn't need cinterop for the iOS app

[James Good]

Just found, it's a deep dive talk, commenters seemed to have liked it

[James Good]

https://youtu.be/5QPPZV04-50▾