I have made a <small sample of a memory leak> that...

# compose-ios

[Brendan Weinstein]

I have made a small sample of a memory leak that occurs when using a ComposeUIViewController that wraps a UIKitView that wraps a native ios view.

I am pretty sure the offending code is tied to passing a function reference that produces the native view to kotlin

let mapboxVC = Mapbox_iosKt.createMapboxVC(
         createMapView: { [weak self] in 
            MapWidget(frame: self!.view.frame) }
       )
        let secondViewController = SecondViewController()
        navigationController?.pushViewController(mapboxVC, animated: true)

Has anyone else dealt with this and can recommend a workaround?

What's bizarre is if I switch to using ios' default navigation bar for back navigation, then I cannot reproduce the memory leak. I've tried wrapping the function reference in a WeakReference on the kotlin side and clearing the WeakReference when UIKitView::release is called. I've also tried making my own ReferenceHolder class on the swift side that can nil out the MapWidget reference when UIKitView::release is called. Neither approach has mitigated the memory leak.

[लातों वाला भूत]

Can you share the stack trace?

[Brendan Weinstein]

Actually, I am not getting a stacktrace per se, but xcode shuts down the app when debugging w/ this message if I keep hopping back and forth between the viewcontrollers for 2-3 minutes

[लातों वाला भूत]

@Brendan Weinstein https://github.com/JetBrains/compose-multiplatform/issues/3201
Might be helpful
What version of Kotlin are you using?

[Brendan Weinstein]

I am using kotlin 1.9.20 and compose 1.5.10

[लातों वाला भूत]

Issue states this was fixed in Kotlin 1.9

[Brendan Weinstein]

The leak of ComposeWindow itself (but not all associated resources) is fixed in this PR

Looks like the ack that there might be more mem leaks even after that fix.

I'll work on drafting up an issue for that repo

[लातों वाला भूत]

A reproducer repo would be helpful in that case

[Brendan Weinstein]

yup, I forked the jetpack compose multiplatform template and made a PR against it that reproduces the issue https://github.com/brendanw/compose-multiplatform-template/pull/1

[Brendan Weinstein]

github issue created here with screen recordings of how to reproduce -> https://github.com/JetBrains/compose-multiplatform/issues/3958

[लातों वाला भूत]

@Brendan Weinstein Were you able to find a solution to this?

[Brendan Weinstein]

yes...I shifted my app to use a single activity/viewcontroller design that fully uses compose for navigation. there's no place where you'll go Native ViewController -> Compose VC -> Native ViewController any longer.

this resolved the memory leak.

I just had three screens left in my app where I was using a native activity/viewcontroller. one of those screens was the core screen of the app and one I will iterate on quite a bit, so it was worth the extra work to re-write to compose. The other two screens are less likely to change in the future, so I just asked chatgpt to help me "re-write this activity as a standalone view" (and same for viewcontroller), and then made wrapper compose components that use UIKitView+AndroidView to render the corresponding standalone views. gpt code needs massaging, but helped speed up the refactor.

[लातों वाला भूत]

Alright. What If you want to implement Social login for users
Those will use Login Modals opening their own VC
Forming Compose VC -> Native ViewController -> Compose VC

[Brendan Weinstein]

sorry, realizing the way I am writing may not be explicit. the mem leak I have in the sample code occurs when

1. user starts app experience on Native ViewController A.
2. user launches compose ViewController B from NativeViewController A
3. user back navigates from compose ViewController B to NativeViewController A
---

You should be fine if you have a flow like:

1. user starts app experience on Compose ViewController A
2. user launches Native ViewController B from Compose ViewController A
3. via deeplink/intent user is returned to Compose ViewController A
Not sure if such a flow could support social login, but I believe you would not hit this problem with that flow. The problem appears to be specific to back navigating away from a compose viewcontroller.

it's been a few years since I've implemented social login, and I only did it on android, so not sure if this would work for iOS.