I wrote a detailed article on the MV Architecture that I am using. You can read about it here: azamsharp.com/2022/10/06/practical-mv-pattern-crud.html

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.

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.

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.

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

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?

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).

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 ?

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?

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

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"

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.

The purpose of MVVM, MVI, MVC, MVP etc is to separate code with similar characteristics to keep the code organized. MVVM does this very well, it takes out variables and functions that depend on or interact with the domain/data layer and keeps the view as minimal as possible with maybe a few states for view manipulation like opening a dialog. (If you have a lot of states holding data in the view those should probably be in the view model using published). This separation increases readability and testability.

please do a video that shows your example

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

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

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

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 🙂

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.

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.

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.

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.

I find this is actually misleading. React + Redux architecture has components what a ViewModel does , it just uses different terminology. You never pass a service class directly to the UI in a react app and call it from there. Purpose of a VM is do the model-to-view preparation so , that logic is testable easily and you don't have to alter model for different view representations and your models can stay agnostic of your views. In a redux architecture you can never directly mutate the single source of truth from your view, you have to dispatch actions and follow their uni directional data flow. Biggest issue with your approach is now your single source of truth is not thread safe in Swift. You have to manually do it, specially in 'counter' example. In this example it seems ok since there's only one method accessing it, but in a large project this could be a huge problem. And also this approach introduces side effects to your View, which is never the case with redux architecture. To deal with side effects we usually use middleware such as redux-saga, or redux-thunk, because reducers must be pure functions and can not handle side effects. So 'effects' in sagas or 'asynchronous action creators' in thunk, actually performs what ViewModel does in an MVVM architecture in my opinion. If you like redux architecture in a SwiftUI app, you should look at The Composable Architecture introduced by pointfree.co team which is a proper usage of that architecture in iOS.

🔥

emmmm, interesting. I have been using MVVM for all my SwiftUI project, I felt noting wrong with it tho... I have heard some people talking about this MVVM pattern is not good for SwiftUI, I might need to look up more articles to get more info.

Full projects with MV on Udemy please

This is pretty bad advice to be honest. Making your view layer directly dependent on your network layer goes against so many architectural rules. Unless you're working on a small personal project, this is a sure way to make your life harder in the future.

I personally don't agree taking business logic at the Model Level. Each View has its on view logic based on what it renders. In any real time project iModel will end up having to many functions which breaks the SOLID principle. Again If you are making any changes in Model level function, it might affect some other function thus increasing the risk of other failures. Even the view will endup doing so many things in this approach thus violating Single responsibility and other architectural pattern. For testability as well you will end up depending on your View, thus migrating back to MVC -- I can call MV is nothing but MVC where VC is being presented as View. Also you talked about redux, Redux is much better then MV as there the Model is not handling any sorts of Logic For small demos its good but for a scaleup project it will fail definitely .

I’m totally not agree with this. You skip whole layer and just transfer same logic to other layers. UI layer should keep only Ui elements and really simple logic. Validations should be outside of UI and service logic. First because for Unit tests and second for services should not manage this validations. If you work on small app this could work pretty well. I worked on a medical application with 50 fields of interaction and validations, without VM this will be nightmare.

Considering MVVM patern in SwiftUI, the V is the body property and that's it. The most important is not to put any logic / calculations in body property.

it will looks too ugly bro, i can understand from your perspective but coming from android background I really prefer abstractions

Bro... first off, if you are closer to the React-verse, you'll know that Redux (and similar) are on the way out. They have been for years. So, suggesting we switch to an outdated design pattern is not great advice. Additionally... you area also just talking about semantics. Those "services" you point out, are just view models with a different name. A class that conforms to an ObservableObject is a View Model. You can call it a service or anything else... that's irrelevant. The patter is still the same. Yes... some of them should be singletons and we typically refer to those as services, but the structure is the same. Environment objects have their place as well, but as you even pointed out... they don't always have the behavior you want. A mature developer doesn't hang their hat on one pattern over the other. A mature developer chooses the write patter for the desired result. It's good for youtube views, though, I guess. Even if it kind of hurts your reputation as a developer.

React in more mature than cf flutter? Dude, look again. Also, MVVM is to separate view from logic. @State if for local state only

I find this moving away from MVVM troubling, to be sure. Call it what you will, MVC, MVVC, ABC...they all strive to do one thing: maintain a Separation of Concerns (SoC) so that the code is clean, short, sweet, and easy to understand, maintain, upgrade, and refactor. Moving away from MVVC because of the exceedingly weark reasoning ("SwiftUI Views are also VMs") is to hinge one's thinking on a technicality, while forgetting the massive benefit of using an architecture that demands SoC is enforced. When I look at SwiftUI code for a VIEW, I do NOT want to see clutter, code that is not even the concern of the VIEW, except to call it as a service. What I want to ONLY see is presentation code specifically for that VIEW, and in the form of calls...let the service or network of model or DB layers worry about specifics. Additionally, the more code you clutter the VIEW with, the less sharable it is, the harder it is to maintain, to understand, to support, refactor and modify. Lets not go back to monolithic programming!!

haha . the long topic i would to said a long time ago. keep as simple stu***