
Kotlin Multiplatform for Android and iOS - andraskindler
https://www.kotlindevelopment.com/kotlin-multiplatform-in-action/
======
oropolo
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
> 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
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
Windows tablets, laptops and 2-1 devices are quite mobile to me.

~~~
rad_gruchalski
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.

~~~
pjmlp
The car computer already takes care of that.

------
dglass
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
I'd suggest to use SQLite as a persistent storage. It's very fast, convenient
and cross-platform.

~~~
sidlls
Room/LiveData are abstractions over the persistent store but by default/in
practice they abstract over SQLite.

------
jaegerpicker
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.

~~~
tlarkworthy
Some of the firebase apis have c++ implementations:
[https://firebase.google.com/docs/cpp/setup](https://firebase.google.com/docs/cpp/setup)

~~~
jaegerpicker
Yep just not the main one I need (FireStore)

------
hashrate
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
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
JavaScript is also an impedance mismatch.

~~~
aikah
> 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
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.

~~~
aikah
> 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.

Well like it or not JS is first class on both platforms as they both have a JS
engine at the developer's disposal, Kotlin or C# aren't.

~~~
pjmlp
I don't know about iOS, but on Android it surely isn't first class, the
development experience is even worse than using the NDK.

If it was first class, there would be official Android APIs for JavaScript,
debugging support on Android Studio, project templates on Android Studio.

Instead it is a web widget with its own little island of HTML 5/CSS 3, hardly
first class.

The support is not much different than getting chromium and compiling it with
the NDK.

The only mobile platforms where JavaScript is first class, alongside the other
platform languages is on ChromeOS and UWP.

~~~
aikah
First class because there is no need to deploy your own JS engine on both
these platforms, you can argue all you want, both have a webview/js engine API
that are part of their respective SDK.

~~~
pjmlp
That is not what first class means.

A language is first class when the complete SDK stack tooling has support for
it.

IDE, debugger, docs, project templates, profiler, OS APIs.

~~~
aikah
> That is not what first class means.

That's not what first class means to you. You can't just make up the
definition you want just because it's convenient for your. First class means
it runs on the platform without any form of external or third party runtime.

~~~
pjmlp
The point is that you want JavaScript to be seen as first class no matter
what, because it fits the React Native story, even though it requires manually
written FFI for the platform APIs.

Hey, by your definition even web pages are first class on mobile devices, as
they don't require any form of external or third party runtime, maybe we can
even call them native apps!

If JavaScript doesn't require any form of external or third party runtime,
then why does React Native bundle JavaScriptCore?!?

[https://github.com/react-community/jsc-android-
buildscripts](https://github.com/react-community/jsc-android-buildscripts)

------
theWheez
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!

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

------
masterp
Looks promising!

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

