STOP using MVVM for SwiftUI | Clean iOS Architecture

What is your favourite Design Pattern in SwiftUI?

Very interesting. Just wondering how this would simplify getting automatic coredata database updates that @FetchRequest offers
Thanks

Can't understand the point of this video. You've described the mvvm pattern.

can you do a video about TCA architecture>?

He’s just creating flat scopes that will inevitably cause massive memory and scoping issues for redrawing once you have to add more than a single screen to your test app. Would not recommend doing anything similar to this. There’s really no pattern here, and the way he’s managing the view model makes me think he doesn’t even understand why you’d want a view model in the first place or how you’d write tests to cover this monstrosity

Well, I learnt how mvvm works thanks to you.

I think the author’s efforts in making tutorial videos are helpful for the most part, but going by this video he is completely leading new and inexperienced SwiftUI developers down a rabbit hole filled with frustrations.

There’s absolutely no advantage to doing this “pattern” over MVVM. One of the main reasons for these UI patterns is to make it easy to implement automated tests on the code base, but he didn’t even demonstrate how this “pattern” of his makes it easier to test.

Meanwhile, why do you use optional/nil parameters for the “UserProfile” struct initializer instead of just using a more idiomatic default initializer/method parameter values?

All in all, thank you for making this video but I advise other watchers to be more circumspect with what they “learn” from it.

Just curious: with this approach, how do you handle the case where one observed resource needs to be shared and observed by multiple views ?

It is really distracting to watch you look at keyboard every time you type something. Stoping in middle to check what you write and then keep writing. How many years of experience do you have in order not to be able to type without looking at your keyboard?

So just Model, View, ViewModel EXCEPT we call it Identifiable, View, Observed. GENIUS.

Came here for the comments. Another clickbaity video. MVVM all the way. Don’t respond with a link to another video like you do with all your other replies thanks

What about when using concurrency (async/await)? How does that work with IVO?

You seem to be promoting MVVM, even though you say otherwise. One of the hallmarks of MVVM is testability, and I find it odd that the folks taking the time to write articles about why MVVM doesn't work with SwiftUI, conveniently leave out how one might otherwise unit test their code.

This is just MVVM renamed

Love this refinement on the MVVM pattern. I’ve implemented similar patterns in Angular2 in the web side.

Nice walkthrough Alex!

Looks like MVVM with a different naming ) But anyway, thank you for the video )

Please stop using the clean architecture label in this videos. This is just MVVM with makeup

If you return something that is unstable, like UUID() or an index, this means you get a new object each time you get the object and this will kill reusability and can cause epic memory and layout process usage beside view management issues like transition management and etc.

Hello, thanks for the explanation, I applied it in a demo that I am making to practice SwiftUI, but I have a doubt,
Could you give me an example of where I should declare an EnviromentObject? would it be inside the View or inside the Observed class?

Can you show us how to write Unit Tests with this pattern?

i heard is first time, from you, thank you to make us noticed

I agree! View in SwiftUI is the View Model.

how about the memory cycle in Observed's completion ?)

the init func is really a bad practice,
why not give Date() instead of nil as the default value

As my opinion this approach is bad shit. We can use only VM (veiw, model) for SwiftUI app.

How?! How did you change -> to an arrow?

Thank you for this tutorial. It is the cleanest and easiest to understand. I've viewed many MVVM tutorials, and they are usually convoluted by using components that detract from the basic inter-file communication. This makes it more overwhelming to visualize. Your example is straight and to the point, with no distracting "extras". I also really like your teaching style, and look forward to following more of your tutorials. Thanks again!

How would you share an observed object between several views?

Why I like the concept for it simplicity it may end up creating difficulty for a medium or large project. The layers are tightly coupled so maintaining the code will become a big issues quickly. I always advocate for separating business logic from every other layer/part of your code and business layer should never depend on any concrete implementation of any other part of your code.

It might work for small projects. But for medium and big projects, with thousands of business rules, it will just fail miserably.
MVVM remains the best choice for any iOS project, specially big ones.

There is no difference from MVVM and what you've described here apart from just putting a different label/name and made such a big claim to "STOP using MVVM". Was expecting at least some challenging arguments and new solutions exclusive for SwiftUI. We us this in our projects.

looks like renamed MVVM with outdated GCD

IMO You just renamed ViewModel class in MVVM to Observed

Besides the naming and nesting one type into another, how exactly this pattern differs from a regular mvvm?

Why does struct Profile have to be Identifiable ?

This looks very interesting. Will try it out.

You almost addressed something which I've been struggling with, so I'll ask you here..... Hope you don't mind.

Many apps have a sign-up/sign-in ability and then a User Profile page that can be filled in. But....what if the properties in the User struct are optional? Mine has `name` and `email` as Strings, but then I have 5-10 other properties which are all optional: dateOfBirth: Date?, gender (an optional Enum), heightInCM (optional Int), and more. Following Peter Friese's Books app, I like the idea of having one view to display the User Profile and clicking "Edit" to update the User's properties. But, if the user edits their profile but only adds one value, say their birthdate, and doesn't change the other values, how will they maintain their nil values? I can fake it for anything that uses a TextField, but for Pickers, Toggles, etc....there doesn't seem to be a useful, non-clunky solution.

If you have any thoughts, ideas, suggestions - even other places I could ask that are not as judgemental as SO - I'd be happy for any pointers.

Thanks again for you interesting video.

Going to try to use IVO for my second app. Wish me luck!

Why did you use an optional value instead of a default parameter value?

No offense but i feel like put functions in the views kind of messy to me , I prefer mvvm I’d say

This is basically MVVM but the Model has to be identifiable and the view model is inside the View

which Xcode theme you are using, it looks decent and clean.

Can the identifiable be a Core Data Entity?

Hmm interesting : ) what about navigation?

HI Rebel! Im new-ish in iOS dev, curious to know use cases for this pattern? Should I use this for my job or personal project? I do like how this reduces the amount of models (or view models) to create especially if the Model or ViewModel is for that specific View only while at the same time easier to set up in the beginning.

This almost feels like MVVM, with the difference of naming and access. Is this still easy to test?