Hey! Bit of an in depth question, but I’m super interested in hearing what your approach is on this problem: I’m currently sharing all of my logic from the ViewModel upwards in KMM. So I’m using an actual/expect construct for the VM, where the android VM uses the jetpack viewmodel, and iOS uses a ‘default’ class. Then I’m using Koin for dependency injection, which works great on Android since there is a simple

viewModel

scope. But I’m running into problems on iOS with regards to the lifecycle.. Currently my VM is marked as a singleton for iOS, however there are a couple of problems that arise: • Initially I thought it would be a good idea to cancel the scope in the viewModel on viewDisappeared, but when I’m navigating back to that same screen Koin will provide the same VM with a cancelled coroutine scope, so that breaks stuff.. • Changing the viewModel to be a factory solves this problem, but then I can’t retain state across screen navigation, which isn’t the end of the world and I can make it work, but it seems like it’s limiting? It also introduces the problem of somehow having to manually save state like scroll positions What are your approaches to the lifecycle of viewmodels on iOS? When do you cancel the scope? Does the VM retain state across navigation?

Our approach has been to create view models independently on iOS and Android as they do have different lifecycles and different ways of interacting in some cases. We expose flows from a model cache and our repositories update the model cache with the data they fetch. Those model cache flows are consumed by the platform independent view models.

I came across this the other day, might be relevant for you: https://www.marcogomiero.com/posts/2022/improved-kmm-shared-app-arch/ You can see an example of cancellation you mentioned in the

KaMPKit

sample: https://github.com/touchlab/KaMPKit/blob/main/shared/src/iosMain/kotlin/co/touchlab/kampkit/models/ViewModel.kt

So, looking at the first article you linked @Matti MK, I think that approach could work but it’s not exactly the same as sharing the viewmodel across platforms. What I did for now, and what works for our usecase, is shortening the lifecycle of the iOS viewmodel. What I figured out was that functions like

.onDisappeared

aren’t called when navigating to detail screens on iOS. So what we can do is: • Initialize a new viewmodel on every

.onAppear

, can keep this viewmodel in memory through an

ObservableObject

. Whenever we navigate to a detail view, the VM is retained, so coming back to the original screen leaves the original state. But when navigating away from the screen entirely

.onDisappeared

is called, the VM is cleaned up, and once

.onAppear

gets called again a new instance of the VM is created. • We use Koru to map kotlin Flow to swift combine, this basically allows us to keep all the view state logic inside the VM except for: observing state changes (through combine).

I’m doing the same as you, but I’m mainly keeping an eye on memory leaks and memory consumption: works well. I’ve not yet had serious state issues. However, I’m leaning more and more towards sharing UCs instead of VMs and extracting as much business logic as possible to the UCs themselves

That is indeed very similar to my setup. Why are you considering moving move logic the UCs? I feel like sharing the view state management in the VM provides a lot of benefit

Depending on the scenario really. But it’s mainly for the reasons you mentioned. I feel having “native” state management in VMs would be a better option, however, I’ve not yet looked into it more closely. Moreover, I’m moving towards having all business logic into UCs while VMs would simply have logic such as

showError

and

showLoading

etc on VMs. KMM VM sharing does work very nicely towards Android, though.