Hi There:wave:, we have coming across kind of bloc...

# multiplatform

[Suresh Maidaragi]

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

[Suresh Maidaragi]

similarly we generated .aar to use in Native Android
we see native android app size is increase by just 5MB compare to iOS 45MB

[tylerwilson]

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:

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.

[Suresh Maidaragi]

@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..

[tylerwilson]

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.

[kpgalligan]

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?

[Suresh Maidaragi]

binary impact on the device

is that on the dev machine folder or is that the binary impact on the device?

[Suresh Maidaragi]

Code has lazy list with custom row items like
Video player, Audio player, Image, multiple choice field, MathJxview, Dragging gestures, typewriter effect text

[kpgalligan]

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.

[Suresh Maidaragi]

I assume you're using Multiplatform Compose.

Yes

[Suresh Maidaragi]

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

[kpgalligan]

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?

[Suresh Maidaragi]

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

[Suresh Maidaragi]

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.

[kpgalligan]

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.

[kpgalligan]

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.

[kpgalligan]

Trying to "fix" MP Compose hosting "heavy" media views is just going to burn time and cause a lot of frustration.

[kpgalligan]

That's actually what our code lab at KotlinConf is all about...
https://kotlinconf.com/speakers/16e157d4-9d83-452f-a1f3-7feeb7e32d1f/#Multiplatform%20Compose%20+%20SwiftUI%20=%20The%20Native%20App%20Future

[kpgalligan]

We'll be doing the same thing over Zoom after, but the concepts are pretty straightforward.

[Suresh Maidaragi]

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.

[kpgalligan]

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

[kpgalligan]

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.

[Suresh Maidaragi]

@Shwetansh Srivastava

[Suresh Maidaragi]

@Rohit

[Suresh Maidaragi]

@rakesh goyal

[Pamela Hill]

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?

[Suresh Maidaragi]

Yes DM'ed you..

[Elijah Semyonov]

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?

[Suresh Maidaragi]

If we don't set flag

Xbinary=disableAllocatorOverheadEstimate=true

And GC threshold below 1k, runtime memory consumption increases and iOS system let crash the app.

[Suresh Maidaragi]

Hi everyone, we debugged another KMM project which we have built, that app also using the min memory around 450MB