Introducing MVVM into your SwiftUI project - Bucket List SwiftUI Tutorial 11/12

[@anotherguycalledsmith]

Dear Paul, This is pretty much the _most_ important video that you have published for a very long time! You might not think so, but for the self-taught average iOS/watchOS… programmer it is very difficult to properly organise larger projects. Of course, you would still like to keep some of your best tricks up your sleeves, but it is utmost helpful for all of us to see what goes where and what is best practise when it comes to app architecture. Please help us more how _not_ to end up in MVs (Massive Views). This extension tip is very useful and effective, thanks a lot!

[@jur9103]

@Paul Hudson MVVM is nice, however as you said does not work with swift data nicely. What is YOUR opionion at this moment what app architecture would fit it better? I also like your comment at the end about experimenting. This help us move forward.

[@Spacer-l3j]

Use MVVM with Core Data for now. Look up the Router design pattern for SwiftUI which decouples navigation logic

[@nsuinteger-au]

How do you handle dependency injections for view models in a cleaner way

[@Contreras04]

Man I wouldn't be an iOS developer if it wasn't for you. Thanks for all this content ❤

[@peterhelms6839]

Excellent description on how to segregate model and view, I have been looking for a way to do it in SwiftUI as Views can grow very big with code attached inside. Thank you 🙂

[@hazel_moonshine]

I'm here for those 2 beautiful dogs

[@morrolan]

Hi Paul. I use this MVVM technique together with the .onAppear that will handle fetching data from API to populate a view. I have found that there are some use cases where .onAppear is not consistenly fired. In your example you are using init on the view model, but this is easy because you are not receiving any parameters. For example when I want to display this view for a product, I would pass the product id, which the onAppear will pass to the view model func loadData. Works great until onAppear doesn't fire.

[@VitaliiTrofymenko]

why do you have @State VM instead of @StateObject?

[@anudeepananth]

How would we share this viewModel across multiple views

[@kimsanov]

What if i wanted further separate model from viewmodel. E.g. put saving and storing to Model class. What is best approach in this case? I'm confused whether Model should be injected in ViewModel? Or there is better approach?

[@supersquare]

You're breaking the pattern. A data structure (model) doesn't include methods, it just describes the structure of some data. Utility methods should be placed elsewhere

[@santhoshVnair]

This scenario is nesting a class (ViewModel) inside a struct (ContentView). Will this create a problem in a document based app, where one might have multiple instances of the same view?

[@supersquare]

Each view creates its own instance of viewmodel. if there are multiple view instances, they each have their own separate state. state cannot be shared between instances. for certain cases this seems nice

[@anmolrajpalofficial]

I am confused. When I downloaded your project for final source code, it has @MainActor ViewModel of type ObservableObject but in your tutorial it's @Observable micro. In addition to that, I see you have changed @State viewModel to @StateObject viewModel in the ContentView. Can you please explain the reasons?

[@tainc]

`ObservableObject` and `StateObject` are the old way. If you are targeting iOS 17 or later, you should use `@Observable` and `@State` like he did in the video. At some point he'll update the sample code to match.

[@tombruckner684]

What is this dog breed? They are adorable.