Hey, I’m wondering if any of you migrated step by ...
# multiplatform
n
Hey, I’m wondering if any of you migrated step by step existing Android and iOS project to KMP? Something as 9GAG explained here 9GAG Case Study. How big was your app? What is your experience and how much time it took you to do basic setup?
j
200k lines-of-code; took nearly 2 years from pure Java Android app to 1st release running KMP on iOS. The Android version was being actively developed during the time without disruption; some versions released from a mixture of Kotlin and Java etc.
🚀 1
n
Thanks Jan, you didn’t have any iOS app before? Do you also use Compose? I have situation where we have Android(In Kotlin and GQL) and iOS app and I want to merge them and go step by step. For example create KMP project, put constants inside shared module and use it inside existing Android and iOS codebase
j
No, we didn't have an iOS version previously, and we don't use Compose. Instead, we have implemented an own framework that implements Android-alike API, but for KMP / iOS; so the development continues on Android, and the iOS versions are just recompiled from that Android source code.
n
Great insight, thanks
j
Regarding your particular problem, in our case we had a core engine that had no UI and could work +- standalone; that was the first "easy" target. We had converted that to KMP first & set up unit tests + trivial UI for checking that it works on iOS. Then we continued with the UI. If you have something like an independent core in your project, I'd suggest trying to reuse that as a whole via KMP in your Android and iOS apps. Reusing just constants or something similarly low-level might be too much pain, and not much gain.
n
Hm, why do you think there is no benefits of extracting constants? We already use Apollo library that is KMP compatible, so idea was to migrate whole repository module that basically fetches the data from GQL and map it to Data class that is later used in ViewModel. Do you think that is worth the effort and relatively easy to do?
j
I didn't mean to say there is no benefit in that; code reuse always rocks of course 🙂 Just from my experience, it is a bit more painful to use KMP stuff in Swift rather than pure-swift, so in my view, it is better to do something a bit larger with bigger impact (and consequently larger code reuse), to counter-weight the slight inconvenience. Hope that makes it more clear.
Wrt. your "migrate whole repository module that basically fetches the data from GQL and map it to Data class" sounds like the equivalent of what we did with our core; so sounds good to me :-)
n
Amazing, that clarifies things and gives confidence to move forward!