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

Download the completed project here: github.com/two...
Other parts in Project 14:
Introduction: www.hackingwit...
1. Adding conformance to Comparable for custom types: • Adding conformance to ...
2. Writing data to the documents directory: • Writing data to the do...
3. Switching view states with enums: • Switching view states ...
4. Integrating MapKit with SwiftUI: • Integrating MapKit wit...
5. Using Touch ID and Face ID with SwiftUI: • Using Touch ID and Fac...
6. Adding user locations to a map: • Adding user locations ...
7. Improving our map annotations: • Improving our map anno...
8. Selecting and editing map annotations: • Selecting and editing ...
9. Downloading data from Wikipedia: • Downloading data from ...
10. Sorting Wikipedia results: • Sorting Wikipedia resu...
11. Introducing MVVM into your SwiftUI project: This video
12. Locking our UI behind Face ID: • Locking our UI behind ...
Wrap up and challenges: www.hackingwit...
You can find the full set of videos, along with transcriptions, challenges, tests, and more, in my free 100 Days of SwiftUI course: www.hackingwit...
Watch the full 100 Days of SwiftUI playlist here: • Understanding the basi...

[@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!

[@Contreras04]

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

[@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.

[@iLoveAppl3947]

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

[@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.

[@nsuinteger-au]

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

[@anudeepananth]

How would we share this viewModel across multiple views

[@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

[@VitaliiTrofymenko]

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

[@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

[@tombruckner684]

What is this dog breed? They are adorable.

[@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.