Hi folks, I have a native Android project written ...

# multiplatform

[M Peeran]

Hi folks,
I have a native Android project written in Kotlin with all common libraries i.e., API calls with Retrofit, Caching with Room, and UI in XML.
I now want to migrate to KMM.
Do you guys have migrated an existing Android project to KMM before??
If so, then please help me out with your feedback on it.
I wanna know what obstacles I might face during the migration, and things that I must keep in mind.
I don't have an iOS project yet, I want to build it with KMM.

[Pramod]

Specially how much effort it is to move

• Retrofit (network library) to be replaced by KTOR
• Room ( cache library) to be replaced by SQLDelight library
• Native Serialization to be replaced by Kotlin Serialization for all DTOs
?

[Pramod]

@Duane Malcolm @CLOVIS @John O'Reilly do you hace idea friends?

[Łukasz Nowakowski]

If you are creating a new feature then you can start creating a kmm library that you will slowly add to android/ios/other. If you want to port a feature from android to ios in your case I would start from scratch. Using the libraries mentioned above.

[M Peeran]

start from scratch is not the option I have unfortunately!

[Łukasz Nowakowski]

the libraries you are using are not supported by kmm well maybe okhttp and future retrofit but that is some alpha version https://square.github.io/okhttp/changelogs/changelog/#version-500-alpha4

[M Peeran]

yep.
There are not many stable libraries though for KMM, atleast as of now.

[M Peeran]

so many things are in either alpha or beta stage, for a production app, its not a good fit since there are a lot of things that could change/break.

[Łukasz Nowakowski]

But you are confusing compose UI with kmm libraries. You can create kmm library without UI. Compose UI for ios is in alpha/experimental version. You can use kmm library in android with XML/Compose and in iOS with swiftUI or wait for a more stable version with compose UI for iOS.

[M Peeran]

Ok yeah.

[Łukasz Nowakowski]

Libraries for kmm it seems to me that they are quite stabile for about 2 years we have one in production and they are ok ( android, ios ) without UI

[M Peeran]

Have you migrated it to KMM or started from scratch??
How much time & effort it took in the case of migration??

[CLOVIS]

If your app is properly modularized, you can migrate feature-by-feature. Then there's really no time issue because you can continue working on everything else as you go.

[CLOVIS]

Anyway, the time it takes is highly dependent on 1: your codebase is modular enough to allow incremental changes, and 2: the team knows what they're doing

[M Peeran]

yep I agree

[Łukasz Nowakowski]

We started thinking about kmm about 3 years ago, and 2 years ago we rewrote the app from scratch for android + iOS .For 2 years the app has been in production and we have no complaints from iOS users. The most important thing is to understand how kmm works but once we achieved that then it went very smoothly. In our case we had the “common” part done quite well so it was enough to copy solutions from android to kmm in many places. Whether I say it took 2 or 4 months it doesn’t matter from your perspective because we may have other problems to solve.

[M Peeran]

Yeah.
In my case, there's no option to start from scratch as the Android app is in production already and it hasn't been built with KMM in mind.
I think I should wait.

[Vidmantas Kerbelis]

My projects case was that we started off small, always keeping it small and building up.
So, the start was:
• On Android, we had Retrofit,
• Created a multiplatform module,
• Remade Retrofit implementations with KTOR on the multiplatform module, did not use that yet on iOS
• Launched Android into prod with KTOR,
• Success…
• Applied it to iOS
…
And then.. We repeated this cycle with basically everything else from that point on.

[Vidmantas Kerbelis]

Since you don’t have an iOS project yet, I’d personally go for remaking most if not all of the implementations on Android to be multiplatform compatible, modularizing most if not all of the stuff into a shared module and then building up an iOS app

[M Peeran]

makes sense, provided that time is not a constraint

[Vidmantas Kerbelis]

If time is a constraint, I’d say you need to put in some work on figuring out how much it would take to build up a full iOS app, without any shared code, then putting in at least some parts of the code as shared code. Network layer, database layer, maybe some feature-specific use cases..
And cover most of the stuff natively.
Of course, I can’t comment a lot, because I have no idea about the skillset of the developers that are building said iOS app.
Maybe going full multiplatform, even with Jetbrains Multipaltform Compose would be even faster. Too many unknown factors probably for anyone to comment on here 😄

[M Peeran]

yep

[Pramod]

great strategy @Vidmantas Kerbelis, is there a way to do the migration incrementally?

[Vidmantas Kerbelis]

Just from “gut feeling” and personal experience, as I’ve done all of these:

• Retrofit (network library) to be replaced by KTOR

For me it was quite straightforward and simple. The hardest part was the initial setup to get everything right.

• Room ( cache library) to be replaced by SQLDelight library

SQLDelight for me was a bit trickier than Room, again.. the initial setup was mostly the tricky part, when you get one or two use cases going, you start to figure out how everything works and it becomes simple.

• Native Serialization to be replaced by Kotlin Serialization for all DTOs

Kotlinx serialization for me IS the way to go. It’s super similar to something like Gson or Moshi, even simpler, I’d say.

[Vidmantas Kerbelis]

Is there a way to do the migration incrementally?

Short answer: Yes
Longer answer: I know way too little details to comment on this 😄 I know you’re building the iOS app from scratch. I know that there might be a time constraint. Let’s say you have an iOS dev that knows the iOS stack very well, and could build the app quite quickly just by copy/pasting implementations from Android.
I’d say, as you’re new to the Kotlin multiplatform environment - and Android needs some catching up to do on it’s own technologies in your project, - don’t rush into making everything multiplatform.
Start off by refactoring lower level parts of Android - releasing them, at the same time building up the iOS app using those newly written Android parts in multiplatform.
Soo… Specifically start off with the network and database layers.
…
Later on you’ll get a feeling of what to do next once you’re more comfortable and understand more about the multiplatform technology.

[Pramod]

Sounds good, thanks @Vidmantas Kerbelis,

[Pramod]

@M Peeran does it make sense to you?

Start off by refactoring lower level parts of Android - releasing them, at the same time building up the iOS app using those newly written Android parts in multiplatform.
Soo… Specifically start off with the network and database layers

[Pramod]

if could make this work, we can save tons of efforts on iOS side writing the same code,