https://kotlinlang.org logo
Join Slack
Powered by
Hi There:wave:, we have coming across kind of bloc...
# multiplatform
s
Hi There👋, we have coming across kind of blocker🔴 issue on KMM, Due to which we are thinking to drop🫳 the entire project built around 2months. We used framework generated from KMM project and used in Native iOS app, two major issues which we see while using this KMM framework in native iOS app, 1. the iOS framework size is ~45MB 2. the memory consumption on iOS app build is drastically increased to ~1.3GB 3. memory release is not happening due to which iphone is heating, freezing and crashing the app entire app due to KMM framework. if you guys have any recommendation or suggestion to optimise it, would be appreciated. we are disappointed😬🫤 by this two major issues on KMM
👀 3
👍 2
🎉 2
similarly we generated 
.aar
to use in Native Android we see native android app size is increase by just 5MB compare to iOS 45MB
t
Do you have the ability to edit and rebuild the KMP framework? Did you run it in Instruments to see what is being allocated and not released? We had similar issues with performance of the Kotlin GC. Switched to a different version like so:
Copy code
configure(listOf(
        iosArm64(),
        iosX64(),
        iosSimulatorArm64()
    )) {
        this.compilations.configureEach {
            compilerOptions.configure {
                freeCompilerArgs.add("-Xallocator=mimalloc")
            }
        }
}
which really helped our app. We also switched to Ktor 3 EAP which fixes some leaks in Ktor 2.x.
s
@tylerwilson yes
Do you have the ability to edit and rebuild the KMP framework
No
Did you run it in Instruments to see what is being allocated and not released?
tried above snippet, post increasing the memory consumption even after exiting from feature still memory remains used..
t
So likely the library itself leaking memory, not Kotlin itself. I would try an Instruments run to get a rough idea where all the memory is going.
k
1. the iOS framework size is ~45MB
Is that on the dev machine folder or is that the binary impact on the device? I'm assuming that's on the dev machine. The "binary impact" of a framework on device is very different than the size of the framework on disk. If this is a "standard" KMP library and not Multiplatform Compose, 45m would be huge. Agree on trying updated GC. The GC has had significant improvements. KMP doesn't just have "general" memory issues. It definitely sounds like a leak. What is the code actually doing?
☝️ 1
s
binary impact on the device
is that on the dev machine folder or is that the binary impact on the device?
Code has lazy list with custom row items like Video player, Audio player, Image, multiple choice field, MathJxview, Dragging gestures, typewriter effect text
k
If you have 45m as actual binary impact, you're probably not using KMP as logic. I assume you're using Multiplatform Compose. That adds roughly 25-30m, minimum. That's an entirely different discussion. If you're not using MP Compose, 45m would be an enormous amount of KMP code. KMP, as logic, doesn't come anywhere near that size in any reasonable scenario. If you're using MP Compose, you're also shipping skia and a bunch of other stuff. It is a technical compromise you need to be willing to make. Android doesn't have the same compromise. Long story. As for memory leaks, either something in the code is causing it, or the code is holding onto iOS-side resources in a way that causes memory cycles that the iOS side can't resolve. It's possible that there's a KMP issue that's causing all of the issues, but unlikely. Without significantly more details, there's no way to help sort out the issues. If you're using MP Compose, you'll have a big binary baseline to accept. That's the compromise you'll need to accept. On the memory situation, that's likely due to hosting views that are doing relatively "extreme" memory things. Video, audio, etc. How they're hosted, viewed, and likely retained, might suggest where that memory is being consumed. I'm not trying to sound negative, but if you're using a library that uses MP Compose, which is great but relatively new, and mixing in iOS-native components that probably gobble up a lot of memory and don't necessarily cooperate with KMP's GC, you know. It's a lot. Help resolving those issues would require much more detailed info, at a minimum.
s
I assume you're using Multiplatform Compose.
Yes
If you're using MP Compose, you're also shipping skia and a bunch of other stuff. It is a technical compromise you need to be willing to make. Android doesn't have the same compromise. Long story.
We are using skiko and MP compose and bunch other libraries
k
I am curious, as somebody personally, and arguably "formally", involved in the perception of KMP in the community, was that compromise something that wasn't known up front? Was this something that went into the decision to use MP Compose?
s
If you're using MP Compose, you'll have a big binary baseline to accept. That's the compromise you'll need to accept. On the memory situation, that's likely due to hosting views that are doing relatively "extreme" memory things. Video, audio, etc. How they're hosted, viewed, and likely retained, might suggest where that memory is being consumed.
Yes lazylist contains all of this once, and if we keep playing around list(scrolling up/down) memory keeps increasing and decreasing
we are compromised to have increased in binary size on iOS, but memory consumption issue is kind of blocker issue to us, which creates bad user experience, which heats up iphone.
k
As a practical suggestion, I'd swap the Compose MP view hosting a bunch of media views with something native to iOS. I'm not shocked that MP Compose is "not optimized" for that.
KMP allows flexibility. I'd make that specific view a "native" view. Swap the lazy list with a SwiftUI view, and just consume the data from KMP.
Trying to "fix" MP Compose hosting "heavy" media views is just going to burn time and cause a lot of frustration.
We'll be doing the same thing over Zoom after, but the concepts are pretty straightforward.
s
this is great suggestion, again we need to convert is row items view to native swift?
Kevin Galligan [11:09 AM]
KMP allows flexibility. I'd make that specific view a "native" view. Swap the lazy list with a SwiftUI view, and just consume the data from KMP.
k
Well, I don't know your apps, but I assume you have some kind of list data defining what needs to show up. Entries like "video: [url], video: [url], audio: [url], form, video: [url]". That gets rendered by Compose, and the user scrolls through them. On the screen that renders the list, before the list, have a split with an 
expect/actual
. On Android, do what you're doing now. On iOS, host a native view, SwiftUI or UIKit, and pass in the data. Then you just create the same list UI for iOS. If I had to guess, UIKit would be the safer option. SwiftUI is "nice", but for certain types of views, UIKit is a more stable option. In the code lab we're doing, one step adds a map view. Doing that with SwiftUI is "unpleasant". So, that view is UIKit, but then there's a different view that we use SwiftUI. https://touchlab.co/jetpack-compose-ios-interop
That sample actually uses SwiftUI for the map, which is kind of confusing considering the UIKit explanation I just went through. Anyway, that's how you mix views.
👍 1
s
@Shwetansh Srivastava
@Rohit
@rakesh goyal
p
Hi @Suresh Maidaragi. If there is something that you can give us as a reproduceable sample, we'd love to see if there's something on our side we can do to help! Do you think you could provide something for us?
s
Yes DM'ed you..
e
Hi @Suresh Maidaragi Just a couple of follow-up questions: Does the runtime memory consumption increase indefinitely until the OS kills the app? Or does it stabilise at some value (it could be high) and fluctuates around it?
s
If we don't set flag
Copy code
Xbinary=disableAllocatorOverheadEstimate=true
And GC threshold below 1k, runtime memory consumption increases and iOS system let crash the app.
Hi everyone, we debugged another KMM project which we have built, that app also using the min memory around 450MB
✅ 1
d
@Suresh Maidaragi Were you able to resolve this memory issue maybe. I have an app that is 17mb on an Android phone. and is 130Mb for apple devices. Using Compose multiplatform for development
k
Using Compose multiplatform for development
CMP adds significant binary size to support Skia/etc. It is an important consideration before choosing the technology. However, "significant" is in the neighborhood of 20-30 meg. KMP on its own doesn't add much proportionally over, say, writing it all in Swift, but that does depend on your config. Arguably, anyway. 100m of most just code would be quite a bit of code. What's the size breakdown of the app, and what part is just KMP/CMP?
s
In my case runtime memory consumption in iOS was introducing due to lifecycle of viewmodel not adhering to composable and other bad practices in the code. But your questions relating app download( build )size Im aligned what @kpgalligan say's max ~20-30MB size we can compare between native android and iOS, in your case its quite huge in case of iOS, Please check package content in case of ios as like we do in Native Android (Apk analyser )
32 Views
Open in Slack
PreviousNext
Powered by