I've been thinking, one of the big advantages of K...

# multiplatform

[matej]

I've been thinking, one of the big advantages of Kotlin over traditional multiplatform frameworks, like Xamarin, React Native etc., seems to be that it isn't a big idea solution that wants you to marry it, "till death do us part" style. In theory, you could find out that KMP is not for your team, or your project, and relatively painlessly move to a classical native mobile approach, or even something completely different - which is not at all the case for those other frameworks. So, please correct me if I'm wrong, but on iOS, you just have the framework that gets generated, and you could keep that but ditch the KMP toolchain entirely, and piecewise replace what's in the framework, or leave it as it is and use it as a library for as long as it works. But what about Android, is there a similar route that can be taken, or, if you want to use what's in the common code, do you have to drag KMP along with you forever?

[Sam]

My android architecture is app->aar where the aar is a KMP module. If I wanted to dump KMP, I would just duplicate the source files, reconfigure the gradle file and move on. iOS would involve rewriting the Kotlin code in Swift which would be a pain in some cases (concurrency). Thankfully the languages have a very similar feature set.

[kpgalligan]

On the android side, it’s all Kotlin, which is probably what you’d build your android app in anyway. I think the issue would be if you’d change libraries if you moved away from KMP. Like maybe you’d switch off ktor? The “not a big idea solution” is definitely a plus for KMP. The other thing I like to talk about is the Android side is pretty much what you’d do if you were writing an Android app anyway, so moving off KMP for Android is way less work than iOS, which needs a rewrite in Swift.

[Andy Gibel]

having just gone the OTHER way and rewritten thousands of lines of Swift for KMP I can confirm it is a PITA lol. Gave me a new understanding of all the DISsimilarities of the languages for all people talk about the similarities

[kpgalligan]

I don’t tell people they’re similar anymore. They have syntactic similarities, but there’s a lot of difference

[Andy Gibel]

I never knew how robust the matching mechanism in Swift's switch statement for instance

[matej]

Thanks for the input guys. I know KMP is not yet officially touted as primetime ready, and there are some squirrelly parts around concurrency, but the more I think about it, for an app heavy on business logic, and a team with limited resources, the positives of having a lot of the most important code implemented and tested just once, might actually outweigh the moderate-to-low risks involved. The level of lock-in in the other frameworks makes me really apprehensive about using them.

[Andy Gibel]

This was basically my logic - I intend to use it for a production library that is pure business logic. For all the issues I've had, the end result is worth it IMO

[matej]

@Sam Thanks, I think that's exactly what I was thinking! So you have a KMP module as a shared library of sorts, and for Android you generate an .aar out of that, same as you generate a .framework for iOS. It's ready to consume, and if, for whatever reason you should decide to move away from KMP, you could continue using the .aar and .framework as a library, until you were good and ready to move away from it on your own terms. Would that be a correct assumption?

[matej]

@kpgalligan

I think the issue would be if you’d change libraries if you moved away from KMP. Like maybe you’d switch off ktor?

I'm imagining a scenario like the high profile exit of Airbnb from React Native, where after a while they figured it's not for them. After that point, they're stuck with RN in some sense forever until they do a full app rewrite. It would be the same for Xamarin. It's an all or nothing situation, whereas in the case or KMP you could draw a line and tell the iOS developers, for example, from today we're writing all new code natively for each platform. You keep your Xcode project, for now you continue consuming our KMP .framework, which we'll replace piecewise as part of our regular maintenance and refactoring effort, but with very little up-front effort, we can basically consider ourselves a regular native mobile dev shop going forward. Sure, we need to gradually replace parts of the API of our shared business logic KMP library with platform-native implementations if that's what we want, but we don't have to do it all at once. That's a pretty big selling point to bring up to stakeholders in my view.

[kpgalligan]

That is one of the big reasons we’re focused on KMP. The interop story is much better than other options, which means you can introduce KMP for smaller features to try it out without writing a lot of bridge logic, and you can pull it out incrementally if it’s not working out. I also tell people you have an “out” if you’re releasing soon and there’s something you don’t like in the shared code. It’s pretty easy to just “code that part native”.

[kpgalligan]

I don’t have a video, but slides from an intro talk about KMP I did recently. The intro is about why it’s different than other options: https://speakerdeck.com/kpgalligan/kotlin-multiplatform-intro?slide=21

[kpgalligan]

Oh, no, there is a video: https://vimeo.com/371428809

[Andy Gibel]

great into talk @kpgalligan Is it OK if I borrow some of those slides for an internal talk? I basically have your job but at a smaller scale 🙂

[kpgalligan]

Sure! If you need originals I can send a keynote file

[Dmitri Sh]

Same here @kpgalligan - can I borrow? Doing a code week project presenting KMP, this would really help!

[Andy Gibel]

Keynote would be amazing! Thanks

[kpgalligan]

KMP Intro Keynote

kmp-intro-shared.key

[Dmitri Sh]

thanks!

[matej]

@kpgalligan Wow, thank you so much for sharing this, it's going to be incredibly useful for internal discussions!

[mkojadinovic]

Thanks for sharing this @kpgalligan 🙇