KMM? (See updates in the “Port to Apple” thread)

Continuing the discussion from Port to Apple - updates:

Hi!

How is the rewrite of the Android backend using KMM (Kotlin Multiplatform Mobile), going?

Cheers!

I’ll do the updates in the “Port to Apple” thread just to keep it in one place. Also most people won’t know what KMM is. Cheers, Duane.

3 Likes

Congratulations on your amazing Flowx journey (your historical recap in another thread was enlightening). You’ve developed an elite app. Flowx (I’m Gold) and Veryfi (10x more expensive) are my two favorite, and they (veryfi.com) have a building full of developers. You’ve come far pilgrim (Robert Redford movie reference - Jeremiah Johnson). Well done!

There have been many attempts at building tooling for multiplatform apps; mono, Xamarin, Ionic, PhoneGap, Electron, Titanium, Flutter, React Native, .Net Maui, Native Script, Kotlin Multiplatform Mobile (KMM), etc. Could you reflect on how you landed on KMM, and subsequent epiphanies?

2 Likes

@HowHardCanItBe Hello and Welcome to the Forum and Thank You for Using Flowx

3 Likes

Hi @HowHardCanItBe,

There are many new things for me with this development: 100% Kotlin with coroutines and flows, KMM, a new design pattern (MVI), iOS, Swift/SwiftUI, Jetpack Compose, and just redesigning Flowx to cope with future features. So there are many moving parts but I’ll chat about KMM which I’m optimistic will do the job well in a native way.

I have been watching cross-platform frameworks for many years. I tried Ionic and it was all cool to start with but once you got further into the development, it got hard. There was too much magic. I thought Flutter was a good option except for the large package size and some other worries.

I chose KMM because it was fully native in either Kotlin or Swift/SwiftUI. There was no reliance on running Javascript in an engine or ported plugins (Capacitor, etc…).

I have managed to write well above 90% of the code as shared code so there is no issues there. The remaining 10% is UI related with some platform-specific business logic which I use the expect/actual pattern to cope with. The expect/actual pattern works well since it’s really just native code that is pulled in during platform specific compile time.

There has been some niggles (not all KMM), most are a lack of understanding issue:

  • Kotlin’s memory model can be an issue. Objects are locked between threads. There is a new memory model now.
  • understanding coroutines and flows, and how this translates to iOS. I’m still trying to understand this.
  • the graph is initially janky in Jetpack Compose but I’m guessing I can work around this.
  • understanding iOS and how they do things, some of it doesn’t make sense.

Overall, it’s been a big learning experience but positive. I feel I’ve got over the learning curve and the remaining parts will fall into place. I’m highly optimistic KMM will deliver the same as native apps but with 90% of the code shared. There has been a couple of times where I’ve changed something in the shared code and built both the Android and iOS apps to see the change magically just work - it’s a good feeling.

Anyway, that was a bit of a random walk of my KMM (plus other things) experience.

5 Likes

BTW, here is a good comment on Dart/Flutter vs Kotlin Multiplatform.
https://discuss.kotlinlang.org/t/google-flutter-what-could-be-their-reason-for-choosing-dart-over-kotlin/21179/16

It’s interesting both Flutter and Jetpack Compose both use Skia.

2 Likes