Could you share the experienced?
# ios
t
Could you share the experienced?
l
I find that anything I need that interacts with Objective-C compatible libraries only is very easy with KMM. The lack of support for pure swift interop is a little annoying, but understandable. Right now, I feel like having to use SwiftUI for UI (if you don’t have to integrate with the nightmare that is UIKit/storyboards from Objective-C like I do on an existing system) adds some friction, but I’m very excited to see Compose for iOS in the (potentially) near future.
t
So, you just try in the production system? Any have issues in performance?
For today?
If my app is pure swift it is fine ?
l
I converted a production library in our app to KMM. I’ve been happy with it.
Anything in your Swift code you want to call in Kotlin needs to be marked with the objc annotation in Swift.
Performance seems fine. JetBrains says Kotlin/Native is slower than Swift, but I’ve never run into a performance problem that was due to the language.
t
I see . But if I want call some method in kotlin to swift it work fine right?
l
I have a loop running 60 Hz that calls a C library. My profiling shows <1ms in my K/N code and about 7ms in the C library.
Yes. Kotlin code gets exported to be callable from Swift.
t
Woowww nice thankyou @Landry Norris 😁
l
I wouldn’t expect it to always be the easiest to use (async/await and suspend integration exists, but I don’t think it’s done yet, and extension functions in Kotlin don’t get exported as extension functions in Swift last I checked), but it should at least be doable.
t
1 more things. So, the kotlin and swift can share data from kotlin -> swift and swift ->kotlin ? And what the minimum iOS version work fine in kmm ?
l
You should be able to share data between the languages. Note that Swift structs are not supported in Kotlin right now, only classes. Other than that, it’s fine. The minimum version is somewhere in the docs.
t
Noted thank you very much 👌
l
I want to say 9.0, but I could be wrong.
r
@Landry Norris I make my UIs with UIKit in Kotlin, and with some little extensions and wrapping it’s kinda nice to use. Looks a lot like #anko and #splitties. I wouldn’t say it’s super easy, but not having any Swift at all is game changing for me. Kotlin interoperate (un)surprisingly good with… Kotlin. 🙃 But I too am excited for Compose on iOS and common UIs
d
I've lead a team to deploy a commercial cross-platform Mobile App with KMM; it was not an easy journey at the beginning (KMM was 'experimental' at the time!) but the end result was very pleasing to the customer and devs, and continues to be maintained to this day with efficiency of writing new feature logic once. We used MVVM with all ViewModels in shared code - bound to a SwiftUI View layer on the iOS side and a Jetpack Compose UI on Android side. We wrote a small amount of Swift code to bridge Kotlin Flows with iOS's Combine framework. Performance was good! In our case - which I believe is typical - only a small amount of data was being moved around by business logic. Anything performance intensive i.e. animations/transitions is anyway being handled by platform-native View toolkits. The most painful part of the project was not KMM at all but, to my surprise: SwiftUI... It didn't behave as advertised in a couple of cases. In particular NavigationLinks exhibited odd glitchy behaviour when linking into deeper content so I ended up wrapping a trusty
UINavigationController
as a SwiftUI component. Ref: • Barntalk for iOSBarntalk for Android
❤️ 1
t
Cool experienced @darkmoon_uk and @ribesg Thank you
l
@ribesg Is there a library you use, or somewhere these extensions are public? I come from an Android background, and working with Storyboards has been frustrating.
t
I want to try use KMM on my production app but have some worries about the maintainability and performance about the app. Your experienced @Landry Norris @darkmoon_uk very helpful . Thank you. Any suggestions for me in first time migrate to kmm ?
r
No I basically made my own micro framework. It’s just wrappers around iOS views constructors with some default parameters, and a clever DSL for constraints. Once upon a time there were talks about maybe adding something like this to #splitties but eh