STOP Using MVVM with SwiftUI

In this video, Mohammad Azam will discuss how MVVM work against the SwiftUI framework and makes things harder.

Support my work and check out all of my courses:

#iosdev #swiftui Check out my courses at

[bigmtnstudio]

Very insightful. It reminds me of what is said a lot in our Utah Slack group when a person is having too much trouble organizing their project: "Don't fight the framework." It just leads to too many unnecessary headaches in the long term.

[yhmlco]

Not convinced. It may be that we write different kinds of applications, but in the banking and financial applications that I write having a VM is a requirement in many cases simply in order to correctly handle differences in account types, payment types, and so on. 

You also conflated a few issues in regard to mapping server entities to view model entities and the need for a "view model" to do so. But if we simply consume the items directly from the server as you recommend, then both the code for the "view model" and the "web service" are now identical, and all you've done is change the name of what they're called.

A VM also helps when you need to manage state from multiple sources and services. Say, cross-matching a list of account permissions obtained from a repo with user information obtained from the auth system, also with states controlled by user preferences and by feature flags also returned from the server. That code isn't wanted in the view.

Moving on, in many cases form validation isn't field-only, but also occurs across multiple fields. Again, you punted and indicated that one could add some sort of external "validation engine", but I feel like you once more decided to add the same ObservableObject... with a different name and coat of paint. "It's not a View Model! It's a Validation Engine! For that View." ;)

I'm also not quite as sanguine about discarding unit tests on complex entities managing complex states. Your simple example doesn't need them, but then again, simple examples rarely do, and most real-world apps aren't quite so simple.

Now, if you were to ask me if EVERY view needed a view model, then I'd agree and say no. VM's are a tool to be used when needed.





The way I look at it, Apple provided a lot of shortcuts and built-in property wrappers to handle some of the most common use cases people might need. Step outside of those common use cases, or when an app starts increasing in size and complexity, and you rapidly reach a point where shortcuts simply don't cut it.

[ashishlanghe]

Thank You Azam, for your quite good clarification on "MVVM with Swift UI" is not a good choice for building SwiftUI apps. Looking forward more detail topics/articles on this.

[roh]

In the take home projects, where companies want you to write the SwiftUI App in 2-3 days, Which Architectural Pattern would you recommend?
Because TCA would be an overkill for such a small project right?

[tmjromao]

I thought View Model concept derives from Android development, isn't it so? Holds the view data "model" when/while the app is in background, due to the equipment "processing restrictions"

[Ivoshevo]

I like it because it keeps my code clean and I don't get confused.

[ayurockt]

Hi Azam,
thank you for the video and the great article.
Can you maybe also explain in your article how you are managing the preview?
If a view depends on the webservice as an environment object how does this work?

Thanks

[davidagyakwa]

now I am confused, what does a domain layer look like, doesn't he view model essentially contain logic for the screen in question ...very confused right now

[jloos]

I used MVC, MVVM and other concepts. My biggest concern with MVVM is that it can get pretty messy and it feels like you also violate the DRY principle. Your view needs Data, so it talks to a "getMyData" function in the ViewModel and the ViewModel calls a "getMyData" function in the service class which finally gets the data. It also gets complicated when one model needs to cross-reference data another model already holds. For example when your class responsible for a users post wants to fill in the user object for the posts creator without doing another API call. I do know there are ways to do this, but it feels overly complicated. I don't know if it is the right way to do it, but it works for me so far. I use the View as a ViewModel and I create a "Model" as my general service class which I use as an EnvironmentObject throughout my application. For not ending up with a two kilometer long file not being able to find anything, the class only contains the basics eg. properties. Any function group I would have before put in their own service, I create an extension of my model in a seperate file. This way I can keep my code clean, easy to find what I am looking for and still being able to access all data I need from throughout the whole application if needed.

[zurvey]

I love how he annotates as he explains. Does anyone know what app he's using to do that?

[saurabhbisht]

How would you write Unit test cases when there's no View Model. How would you make sure Dependency Injection and Inversion along with that. With view model we have the validation and the api result available at one common place. Any views on this ?

[htqyshs]

Hi,
do you have opinion on following clean architecture for Swift UI app? Kindly comment and share your views.

[AndyJMacLeod]

There’s performance, code readability and maintainability considerations.

Abstracting the logic from the views still probably makes sense in larger applications, and if you are having different views for different sized devices.

[programadorveiaco]

In my opinion, MVVM tends to be a kind of Global variables, and, for my experience, tends to inject sources of problem in complex models. So I totally agree with your advice.

[davidagyakwa]

please do a video that shows your example

[marcinfrydrych]

Hello Mohammad. This is a surprise for me. You are a great supporter of MVVM. Paul Hudson is very skeptical about MVVM in SwiftUI. Apple in their own example codes does not use MVVM patern. What do you think about VOODO architecture presented by Mark Moeykens?

[geildesignt]

Lol, yesterday inbought the course for mvvm in SwiftUI on Udemy from you and I was referred to a video and after the video was this Video suggested. Now you owe me a course where I can use this without vm. 😅 you’re a really good teacher.

[wmblemania]

My opinion: the only validation I'd perform in UI is view-based validation (e.g. the enabling/disabling of a control in response to entering characters in a text field), rather than business logic validation.
Any such UI validation should be as simple as possible, and if it's messy at all -- i.e. it makes the view code hard to read -- then the model should handle that, either itself or through services.
The view should be as dumb as possible. I don't think that philsophy has changed between UIKit an SwiftUI. It shouldn't know much about the data being passed in.

[aurelienporte]

Imo, the debate shouldn't be about whether a VM is needed. Instead, it should be about what's a good home for VM logic. In SwiftUI, it should be in a View wrapping your pure UI-code View.

SwiftUI Views are lightweight so it should have no impact on perf or memory. And the introduction of the Observation framework also helps to go in that direction (in the sense that people will be less prone to introduce perf issue when injecting properties).

[NRepairde]

I feel 💯 the same since coding more and more apps. The first lines work well, then I am getting frustrated that MVVM hints me. Are you planning on updating your Firebase-Courses on not using MVVM anymore? That would be great 🙂