BLACK FRIDAY SALE: Save big on all my Swift books and bundles! >>

Is MVVM really a valid approach?

Forums > SwiftUI

I wanted to bring up some discussion I encountered surrounding architecture discussed within:

https://azamsharp.com/2022/07/17/2022-swiftui-and-mvvm.html

It looks like there is a lot to be said about how MVVM is interpreted in SwiftUI/Swift.

In the link above, there is a lot of advocacy toward a pure MV approach (technically it is still MVVM because the SwiftUI Views are effectively doubling as the ViewModel AND the View). However, in practice, the MV approach is named such because you don't end up writing lots of ViewModel objects.

I see that there is evidence supporting an MV approach can yield both cleaner code, and even improved runtime performance.

This does beg the question for me though, why is there so much literature, examples, and support covering the tried & true MVVM approach even if there are performance risks? Is this because the MVVM approach where you instantiate and manage ViewModel objects is just easier to write, and easier to validate the separation of concerns? Did we fall into a bad habit?

If the more purist MV approach is much better - why don't I see more of it? I'm aware this paradigm does get covered in Apple videos, like their WWDC examples, but I do feel the discussion is glossed over in the mainstream world of iOS.

To be clear, the two design paradigms I am talking about are BOTH technically MVVM in a nut-shell. It just so happens that one tries to eliminate a ViewModel object management layer that greatly simplifies design (due to a combination of business logic and model data managed in a single Struct, for example) and improves performance of applications at scale.

Do you see a world where apps should be made without ViewModel objects taking reign? Do you think apps should use ViewModel objects? Personally, I see the benefits of the pure MV approach, but I am deeply weary of migrating to it in a foul-swoop because ViewModel objects treat me so so well...

   

It's basically what works best for you or best for your current use case.

For me I use ViewModels when I have a lot of business logic which I don't what to put in my Views. Personally, I don't care much about such discussions because most of the time they're academic. You should know that they exist and put them to good use for you.

If you run into problems/trouble with one of them (which you certainly will at some time) you have to reconsider your approach anyway.

2      

I agree, it depends a lot on the project and which model you feel most comfortable working with. I still prefer to use ViewModel when there is too much logic, simply because it is more organized.

But for example, every time I use CoreData, it completely breaks my use of MVVM. I have to make a workaround to fit it into the paradigm, that I often wonder if it would be simpler to use a @fetchrequest and leave all that code in the View. I'm still looking for the answer :)

I think all the approaches are valid depending on the project you are working on and how you feel about it.

1      

I use ViewModels in my app as well. Mainly for the same reason, business logic. Small views can do without, but some of the more complex views are in need of them. I use them in conjunction with Core Data, much like Paul does in the Ultimate Portfolio App. I really like the NSFetchresultsController, because you get to work with an Array of your Entity and that makes a lot of stuff trivial, like searching, sorting, etc ...

Honestly, I mostly struggle with SwiftUI still building the UI. Sure, simple UI's are build fast, but go beyond that and things get trickier...

That said, I'm still learning the ropes, so I am no expert whatsoever ...

1      

@CacereLucas I completely agree with your point on the CoreData. I have encountered this as well. I guess it doesn't obey the Combine engine in the same way we experience with other frameworks where you can use certain Wrappers to publish properties.

It sounds like what I'd mostly expect. I personally have a mixture of MV and MVVM implementations in my codebases. When I use MV though, it tends to be a lot smaller in scope. Like, I only worry about a very small sub-view and tiny bit of logic or model data. This sort of lets me use MV to build smaller level components now that I think about it, but my big picture separation of concerns is still very much using a few larger ViewModel objects.

Thank you for your opinions and inputs. This is definitely new ground for me.

   

Hacking with Swift is sponsored by RevenueCat

SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.

Learn more

Sponsor Hacking with Swift and reach the world's largest Swift community!

Reply to this topic…

You need to create an account or log in to reply.

All interactions here are governed by our code of conduct.

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.