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?

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?

I am using kotlin

1.9.20

and compose

1.5.10

Issue states this was fixed in Kotlin 1.9

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

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 Were you able to find a solution to this?

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

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.