what is the best practice with the ViewModel — should it be shared in commonMain, or should it be se...

# multiplatform

[Mohamed Galal]

what is the best practice with the ViewModel — should it be shared in commonMain, or should it be separated into iosMain and androidMain?

[Mohamed Galal]

My question about KMP NOT CMP

[dylan]

If the view on both platform work an have exactly the same interaction I would try to keep it commonmain

[nam]

IMO, viewmodel shouldn't be depend on the OS or view. So, for me, ViewModel should be sharable.

[Masoud Karimi]

It can be helpful to put it in commonMain so that you can share the business logic and doesn't need to repeat it for all platforms.

[Michael Krussel]

From my experience, I did the shared view model following what I would have done with Compose or Android Views and had the view model expose a single state property that represented the current state of the view. This worked fine, until I tried to use it again in SwiftUI. SwiftUI's desire to use two way bindings for everything, made we have to build a second view model that wrapped the original view model and creating the binding that SwiftUI expected. They were dumb view models, but still annoying to write.

This did make we wish I had kept the original view model dumber, made it platform specific, and but the shared logic into use cases. I do think there are libraries out there though, that have solved this problem already.

[dylan]

for the IOS side if you use flows try either Skie or NativeCoroutines

[dylan]

We use the sharedviewmodel directly on IOS and use Skie to get the flows working with SwiftUi

[Michael Krussel]

That works pretty well when you are just showing the user data, but the modeling becomes more difficult when implemented user input other than buttons. I really dislike SwiftUI's binding system because the view model is no longer the source of truth.