Im looking to migrate a kotlin/kotlin compose proj...

# multiplatform

[Jeremie D]

Im looking to migrate a kotlin/kotlin compose project to KMP, is there any decent up to date tutorials?

[Joaquín Pérez]

I dont have one but I have some experience

[Sudarshan]

There's no "one size fits all" when it comes to migrating your Kotlin & Jetpack Compose application to Kotlin & Compose Multiplatform. It all depends on the complexity and the existing architecture of your application. However, the official documentation can help you gain a basic understanding and guide you through the steps to make your app Multiplatform. Check out this guide: https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-integrate-in-existing-app.html#make-your-code-cross-platform

[Sudarshan]

You may also find this article helpful: https://developer.android.com/kotlin/multiplatform/migrate

[Jeremie D]

ok thanks! I've landed on some of those already, but ive not been successful to migrate yet... ive done stuff and then reverted a few times... for now ive decided to migrate to ktor instead of retrofit since that seems like it will be a blocker down the line... ill keep try again with those after and possibly reach out to one of you in a dm in the next day or two if i get stuck. hope thats ok

[Csaba Szugyiczki]

Changing to KMP libs and then try to add multiplatform plugin support could be a way.
Retrofit -> Ktor
Hilt/Dagger -> Koin
etc…

Also starting with low level modules, working your way up to Application could also help reducing the scope of each increment

[Sudarshan]

A quick follow-up question: What dependencies are you currently using in your project? You might need to use the JetBrains version of Compose dependencies instead of the AndroidX ones. Also, would you like to share more details about the problems you're facing right now?

[Jeremie D]

we have quite a bit of dependencies, its an old project. In all cases I was having issues with my build.kt or dependencies- Crap I didnt realize hilt was also needing to get migrated 😁

[Jeremie D]

maybe other problem non ui based libraries include appsflyer, config cat, and Zendesk

[Csaba Szugyiczki]

for those I guess you have iOS specific libs. You must define a common interface for those to be called from common KMP part, and hide the platform specific implementation behind DI or expect/actual

[Csaba Szugyiczki]

depending on how scattered the usage is, it could be a trivial or a really hard task

[Sudarshan]

Oh, that’s right! You should replace Hilt with Koin. But one more thing — you need to make sure the other dependencies you mentioned also have Multiplatform support. If not, consider using their Multiplatform alternatives or writing your own solutions.

[Sudarshan]

By own solutions, I mean using the expect/actual mechanism when no existing community solution is available.

[Jeremie D]

yeah... im ok splitting etc- my main goal right now is shared viewmodels, native views

[Sudarshan]

Great! All the best. Let us know if get stuck at any point.

[Csaba Szugyiczki]

if you will use shared ViewModels but native views then definitely look into SKIE, since it has great tooling to connect async/await with coroutines and flows. Also translating kotlin language features to swift compatible ones

[Csaba Szugyiczki]

And you will also need CrashKios or something similar for meaningful stacktraces on ios

[Jeremie D]

is it easier to use the existing ios views and plug everything in, or is it easier to convert kotlin compose views into kmp to be use on ios- I may have made a poor assumption

[Csaba Szugyiczki]

that depends… If you use a fully custom design language and not make use of the system look and feel iOS comes with out of the box, I would suggest going full kotlin with Compose Multiplatform.

On the other hand if you have native UI look and feel eg. utilizing Liquid Glass effect on iOS 26, then Compose Multiplatform is not the way, and you should stick with what you already have

[Csaba Szugyiczki]

CMP significantly helps. Calling KMP stuff from swift is often not trivial at all.

[Jeremie D]

nice; good insight- our design is lacking in all the ways that would use the ios specific features like glass etc, so maybe theres room there to go to CMP...

[Sudarshan]

@Csaba Szugyiczki I guess going with Compose Multiplatform sounds like a fair deal here! What do you think? Going full native would require a bit more effort compared to Compose Multiplatform. Again, it all depends on what @Jeremie D has in mind regarding which approach to take.

[Csaba Szugyiczki]

I would definitely go CMP in this case. That would eliminate a whole lot of problems around Kotlin to ObjC/Swift compatibility

[Jeremie D]

interesting- thanks for the tips

[Jeremie D]

ill be back with more concrete questions over the next weeks (or days/hours) for sure.

[Sudarshan]

Sure! Don't forget to share your experience with us whenever you're done with migration.

[rhenley]

@Jeremie D Be careful with accessibility in CMP. It is unlikely to be as good as your existing iOS code or what you could achieve with KMP. But if your needs are minimal, you might get by with CMP. At minimum, test your views with VoiceOver as you go along, comparing with how your screens act now.

[Csaba Szugyiczki]

@rhenley If you have concerns regarding this topic please file issues on youtrack. The Jetbrains team was really receptive for my feedback and fixed 2 pretty serious issues within weeks https://kotlinlang.slack.com/archives/C0346LWVBJ4/p1753259277604219

[Jeremie D]

thats a very interesting difference, though frankly, accessibility holds no weight at the company where I work (and im not saying that Im happy with this stance, but just isn't... some things are beyond my control 😿) noted for future projects though
Could I extrapolate that automated testing with click through or whatever will also be harder ? I think many of those systems hinge on accessibility features to select text boxes and press buttons (again, not a concern for this current project at all but good to know for future projects)

[rhenley]

@Jeremie D Understood. It's a common situation.

Regarding automated testing, Compose UI tests can be made to work well in commonTest, with some adjustments for how runComposeUiTest works as opposed to createComposeRule / createAndroidComposeRule (and so how you set up tests and retrieve externalized resources for tests change).

One exception: I have not figured out how to call performKeyPress() , because I can't instantiate a NativeKeyEvent. This limits what I was able to test about keyboard input into `TextField`s. If anyone has figured out how to use those, I'd love to know!