https://kotlinlang.org logo
#compose-ios
Title
# compose-ios
b

Brendan Weinstein

11/20/2023, 9:09 PM
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
Copy code
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.
u

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

11/20/2023, 9:35 PM
Can you share the stack trace?
👌 1
b

Brendan Weinstein

11/20/2023, 10:05 PM
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
u

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

11/20/2023, 10:21 PM
@Brendan Weinstein https://github.com/JetBrains/compose-multiplatform/issues/3201 Might be helpful What version of Kotlin are you using?
💡 1
b

Brendan Weinstein

11/20/2023, 10:24 PM
I am using kotlin
1.9.20
and compose
1.5.10
u

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

11/20/2023, 10:25 PM
Issue states this was fixed in Kotlin 1.9
b

Brendan Weinstein

11/20/2023, 10:25 PM
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
u

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

11/20/2023, 10:26 PM
A reproducer repo would be helpful in that case
b

Brendan Weinstein

11/20/2023, 10:27 PM
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
🙌 2
1
github issue created here with screen recordings of how to reproduce -> https://github.com/JetBrains/compose-multiplatform/issues/3958
👀 2
🤞 2
u

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

11/25/2023, 5:39 PM
@Brendan Weinstein Were you able to find a solution to this?
b

Brendan Weinstein

11/26/2023, 5:03 AM
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.
u

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

11/26/2023, 5:08 AM
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
b

Brendan Weinstein

11/26/2023, 5:22 AM
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.
2 Views