6 ms·

Kotlin Multiplatform for Android and iOS

90 points by andraskindler 8y ago

masterp 8y ago
Looks promising!
- andraskindler 8y ago
  Yup! Still not production-ready, but we're getting there.
jaegerpicker 8y ago
Looks great! My biggest concern and one of the reasons I'm not using Swift or C++ for a cross platform library is that most of the dependencies you (at least I need) need don't support those languages (Auth0, Firebase, Crashlytics etc...). So you end up writing more complex code to make that also work. If Kotlin native can bring those types of libraries to be supported it will be huge IMO.
- abukros 8y ago
  Yes. That’s a problem for MP too. But maybe you can select a proper slice of the application that can work without these libs and implement that code as a shared MP lib.
- tlarkworthy 8y ago
  Some of the firebase apis have c++ implementations: https://firebase.google.com/docs/cpp/setup https://firebase.google.com/docs/cpp/setup
  - jaegerpicker 8y ago
    Yep just not the main one I need (FireStore)
- mamcx 8y ago
  > Swift How you think is possible to use swift on android? The only almost decent way is https://www.elementscompiler.com/elements/default.aspx https://www.elementscompiler.com/elements/default.aspx and is not enough: https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swift_for_androidlinuxwindows_on_2018/ https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swif...
- pjmlp 8y ago
  It is not only a matter of language. The developer experience with the NDK is quite bad, as if Google makes it on purpose for only the persistent developers to actually succeed at it.
theWheez 8y ago
So, so excited for this. I would love nothing more than to be able to create Model and ViewModel code a domain specific cross platform SDK, and have a View implementation on a platform by platform basis for android, iOS, and web. Possible? I sure hope so!
oropolo 8y ago
In essence, JetBrains has caught up to where Xamarin was prior to the announcement of Xamarin.Forms: the ability from one solution to have separate iOS and Android UI applications with a business logic library shared between the two, all written in C# or F# (the two languages supported by the Mono compiler). The main difference is that one of the vendors actually supports the language in question (Kotlin) as a first-class citizen. And going the other way, there's been noise for a couple years that Android apps could be written in Swift, achieving the same effect in reverse.
- the_trapper 8y ago
  > The main difference is that one of the vendors actually supports the language in question (Kotlin) as a first-class citizen. How is this different for Xamarin? C# has first class support on Windows.
  - oropolo 8y ago
    Windows isn't a mobile platform. They tried 2.5 times and have given up. In mobile it's iOS and Android, and neither Apple nor Google recognize C# as a first-class language. If you can write a compiler that emits code that LLVM can compile to ARM binary with Xcode or package your MSIL with a micro .NET VM on Android, then more power to you but Apple and Google aren't going to help you if you get stuck.
    - pjmlp 8y ago
      Windows tablets, laptops and 2-1 devices are quite mobile to me.
      - oropolo 8y ago
        And an AS/400 was perfectly "mobile" to Arnold S. back in his prime. :-)
      - rad_gruchalski 8y ago
        Prerty difficult to find a good dash mount, no usb charging, bit bright at night and having to plug in an external gps unit is fairly limiting though.
hashrate 8y ago
Seems like a gimmick to me. In a nutshell this has the same limitation has Xamarin. The Business Logic is shared , but the UI Logic and the Technical Logic aren't shared or not completely. The Xamarin community has been struggling with this issue for half a decade and they ended up re-writting their own rendering engine[0] (similar to Flutter) in C# on top of Xamarin to obtain truly MVVM Cross-Platform Framework. My point here is very simple , getting Kotlin to run on iOS is great, but it's somewhat a waste of time because of how much time and effort it would talk to create a Runtime or Rendering Engine to normalize UI/UX on differents platforms. [0]https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia
- aikah 8y ago
  The difference is that Kotlin has first class support on Android. Aside from that I agree, Kotlin is obviously second class on iOS. IMHO for simple multi-platform projects I'd use either plain webtechs or react-native. The impedance mismatch between Kotlin and Swift/ObjC is going to be an hindrance no matter what.
  - pjmlp 8y ago
    JavaScript is also an impedance mismatch.
    - aikah 8y ago
      > JavaScript is also an impedance mismatch. Yet both Android and iOS allow embedding a Javascript engine in an native application with no effort whatsoever.
      - pjmlp 8y ago
        I wouldn't call manually exporting Java methods to the WebWidget "no effort whatsover", plus the performance hit of doing cross-language, inter-process calls, in a dynamic language while the platform languages are static.
dglass 8y ago
The thing that I still don't know about are how would things like data persistence be handled in a cross platform manner? I recently built a kotlin Android app for work, and our architecture is tightly coupled to Android's Room database and LiveData objects. Obviously if we build it to be cross platform we wouldn't be able to use a Room database or LiveData objects on an iOS device. Would we have to roll our own persistence layer in a cross platform application? Or would we share business logic but still write a persistence layer using platform specific code? It's not just persistence too. Any lower level API provided by the platform would still need to be written twice, right? Accessing the camera, the devices GPS location, or anything hardware related still needs an implementation for both platforms. Or would we eventually see libraries that would abstract this layer out, similar to react native? Edit: Another thought...I haven't done much iOS development but the whole async nature of Android apps with the UI thread and background threads also seems like it would be a nightmare to deal with in a cross platform way. Does iOS involve a lot of async threads?
- vbezhenar 8y ago
  I'd suggest to use SQLite as a persistent storage. It's very fast, convenient and cross-platform.
  - sidlls 8y ago
    Room/LiveData are abstractions over the persistent store but by default/in practice they abstract over SQLite.
- abukros 8y ago
  I think the way is to write libraries for these use-cases. There is already a persistence lib for Kotlin Native called KNArch.db https://github.com/touchlab/knarch.db https://github.com/touchlab/knarch.db and it supports Android too. We are already using libraries to make easier to use background threads (RxJava, RxSwift) so I don't think it's that hard to implement a cross platform lib for that purpose. JetBrains is already trying to tackle the task with Coroutines for Kotlin Native: https://github.com/Kotlin/kotlinx.coroutines/tree/master/native https://github.com/Kotlin/kotlinx.coroutines/tree/master/nat...
jaxondu 8y ago
What is needed for more adoption is Kotlin SDK for Firebase & AWS.

90 points by andraskindler 8y ago

masterp 8y ago

Looks promising!

andraskindler 8y ago
Yup! Still not production-ready, but we're getting there.

jaegerpicker 8y ago

Looks great! My biggest concern and one of the reasons I'm not using Swift or C++ for a cross platform library is that most of the dependencies you (at least I need) need don't support those languages (Auth0, Firebase, Crashlytics etc...). So you end up writing more complex code to make that also work. If Kotlin native can bring those types of libraries to be supported it will be huge IMO.

abukros 8y ago
Yes. That’s a problem for MP too. But maybe you can select a proper slice of the application that can work without these libs and implement that code as a shared MP lib.
tlarkworthy 8y ago
Some of the firebase apis have c++ implementations: https://firebase.google.com/docs/cpp/setup https://firebase.google.com/docs/cpp/setup
- jaegerpicker 8y ago
  Yep just not the main one I need (FireStore)
mamcx 8y ago
> Swift How you think is possible to use swift on android? The only almost decent way is https://www.elementscompiler.com/elements/default.aspx https://www.elementscompiler.com/elements/default.aspx and is not enough: https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swift_for_androidlinuxwindows_on_2018/ https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swif...
pjmlp 8y ago
It is not only a matter of language. The developer experience with the NDK is quite bad, as if Google makes it on purpose for only the persistent developers to actually succeed at it.

theWheez 8y ago

So, so excited for this. I would love nothing more than to be able to create Model and ViewModel code a domain specific cross platform SDK, and have a View implementation on a platform by platform basis for android, iOS, and web. Possible? I sure hope so!

oropolo 8y ago

In essence, JetBrains has caught up to where Xamarin was prior to the announcement of Xamarin.Forms: the ability from one solution to have separate iOS and Android UI applications with a business logic library shared between the two, all written in C# or F# (the two languages supported by the Mono compiler). The main difference is that one of the vendors actually supports the language in question (Kotlin) as a first-class citizen. And going the other way, there's been noise for a couple years that Android apps could be written in Swift, achieving the same effect in reverse.

the_trapper 8y ago
> The main difference is that one of the vendors actually supports the language in question (Kotlin) as a first-class citizen. How is this different for Xamarin? C# has first class support on Windows.
- oropolo 8y ago
  Windows isn't a mobile platform. They tried 2.5 times and have given up. In mobile it's iOS and Android, and neither Apple nor Google recognize C# as a first-class language. If you can write a compiler that emits code that LLVM can compile to ARM binary with Xcode or package your MSIL with a micro .NET VM on Android, then more power to you but Apple and Google aren't going to help you if you get stuck.
  - pjmlp 8y ago
    Windows tablets, laptops and 2-1 devices are quite mobile to me.
    - oropolo 8y ago
      And an AS/400 was perfectly "mobile" to Arnold S. back in his prime. :-)
    - rad_gruchalski 8y ago
      Prerty difficult to find a good dash mount, no usb charging, bit bright at night and having to plug in an external gps unit is fairly limiting though.

hashrate 8y ago

Seems like a gimmick to me. In a nutshell this has the same limitation has Xamarin. The Business Logic is shared , but the UI Logic and the Technical Logic aren't shared or not completely. The Xamarin community has been struggling with this issue for half a decade and they ended up re-writting their own rendering engine[0] (similar to Flutter) in C# on top of Xamarin to obtain truly MVVM Cross-Platform Framework. My point here is very simple , getting Kotlin to run on iOS is great, but it's somewhat a waste of time because of how much time and effort it would talk to create a Runtime or Rendering Engine to normalize UI/UX on differents platforms. [0]https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia

aikah 8y ago
The difference is that Kotlin has first class support on Android. Aside from that I agree, Kotlin is obviously second class on iOS. IMHO for simple multi-platform projects I'd use either plain webtechs or react-native. The impedance mismatch between Kotlin and Swift/ObjC is going to be an hindrance no matter what.
- pjmlp 8y ago
  JavaScript is also an impedance mismatch.
  - aikah 8y ago
    > JavaScript is also an impedance mismatch. Yet both Android and iOS allow embedding a Javascript engine in an native application with no effort whatsoever.
    - pjmlp 8y ago
      I wouldn't call manually exporting Java methods to the WebWidget "no effort whatsover", plus the performance hit of doing cross-language, inter-process calls, in a dynamic language while the platform languages are static.

dglass 8y ago

The thing that I still don't know about are how would things like data persistence be handled in a cross platform manner? I recently built a kotlin Android app for work, and our architecture is tightly coupled to Android's Room database and LiveData objects. Obviously if we build it to be cross platform we wouldn't be able to use a Room database or LiveData objects on an iOS device. Would we have to roll our own persistence layer in a cross platform application? Or would we share business logic but still write a persistence layer using platform specific code? It's not just persistence too. Any lower level API provided by the platform would still need to be written twice, right? Accessing the camera, the devices GPS location, or anything hardware related still needs an implementation for both platforms. Or would we eventually see libraries that would abstract this layer out, similar to react native? Edit: Another thought...I haven't done much iOS development but the whole async nature of Android apps with the UI thread and background threads also seems like it would be a nightmare to deal with in a cross platform way. Does iOS involve a lot of async threads?

vbezhenar 8y ago
I'd suggest to use SQLite as a persistent storage. It's very fast, convenient and cross-platform.
- sidlls 8y ago
  Room/LiveData are abstractions over the persistent store but by default/in practice they abstract over SQLite.
abukros 8y ago
I think the way is to write libraries for these use-cases. There is already a persistence lib for Kotlin Native called KNArch.db https://github.com/touchlab/knarch.db https://github.com/touchlab/knarch.db and it supports Android too. We are already using libraries to make easier to use background threads (RxJava, RxSwift) so I don't think it's that hard to implement a cross platform lib for that purpose. JetBrains is already trying to tackle the task with Coroutines for Kotlin Native: https://github.com/Kotlin/kotlinx.coroutines/tree/master/native https://github.com/Kotlin/kotlinx.coroutines/tree/master/nat...

jaxondu 8y ago

What is needed for more adoption is Kotlin SDK for Firebase & AWS.