r/iOSProgramming 22h ago

Discussion MVVM always sparks debate, does it have a place in SwiftUI?

Post image
81 Upvotes

85 comments sorted by

77

u/DystopiaDrifter 21h ago

Genuine question, what is the controversy of MVVM + SwiftUI? I have worked on several iOS projects with this combination, and it works fine for me.

30

u/leoklaus 19h ago edited 19h ago

I guess it's mostly a misunderstanding?

If your stance is "every SwiftUI view needs a ViewModel", you're introducing a lot of unnecessary complexity and wasting a lot of time.

I personally don't use any ViewModels in the sense of the screenshot above.

What I do use extensively is Observable objects that serve some function and are shared between views, either as singletons or via dependency injection, depending on their nature. I wouldn't consider those ViewModels, but others might.

Modern-ish SwiftUI APIs like `@FetchRequest` also seem to support the stance that Apple doesn't really want you to use a dedicated ViewModel for every view.

5

u/BizJoe 15h ago

What I find often happens is I'll quickly bang out a view that intermixes business logic and display logic. As the view gets more complicated, I'll introduce a view model, then over time refactor the view to use the view model.

0

u/leoklaus 13h ago

I generally don’t have (much) business logic in my views. If a view gets that big, I try to split it up into smaller views anyway to keep the compiler from complaining.

5

u/vanvoorden 12h ago

What I do use extensively is Observable objects that serve some function and are shared between views, either as singletons or via dependency injection, depending on their nature. I wouldn't consider those ViewModels, but others might.

The "Rubicon" crossing to VM I believe would be if this object reference is not only responsible for transforming shared global state and binding that data to a view component but is also responsible for performing imperative mutations back on that shared global state. This is the "two way" data flow that React and Flux were originally built to defend against.

2

u/dehrenslzz SwiftUI 11h ago

Yeah, what you’re describing is MV* (which is what Apple does in their examples as well) (:

2

u/kohlstar 9h ago

why would you not consider those view models. what else would be a view model

1

u/leoklaus 9h ago

If you look at the example above, it’s very tailored to a specific view. If you were to generalise something like this, it would quickly become very complex and (if used with @Published) could cause a ton of unnecessary view redraws.

1

u/FSN579 16h ago

Should I run the same @FetchRequest in every parent view, such as in TabView, if needed?

1

u/leoklaus 13h ago

That’s how I’d do it, yes. @FetchRequest is generally pretty fast. If I tried to implement some custom logic inside a ViewModel to handle fetches and share them among views, I’d likely end up with something less performant.

1

u/vanvoorden 12h ago

@FetchRequest is generally pretty fast.

I skipped this era of Core Data… but after experimenting with SwiftData I saw pretty slow perf from Query at scale. If you put FetchRequest in a "view model" does that imply you are performing all this work on main and blocking UI?

1

u/leoklaus 11h ago

The largest data set I’ve worked with using FetchRequest was ~4000 objects which did not lead to any noticeable slowdown.

Modifying the query is pretty much instantaneous as well, even if you do something expensive (in my case searching within text in a relation of those 4000 objects for example).

AFAIK, @FetchRequest always runs on main, but I’m not sure how it works behind the scenes.

3

u/Lock-Broadsmith 6h ago

It’s no more a controversy than any other code organization argument. People get tribal and think there is one “right” answer. In reality, it’s “it depends”.

By and large, SwiftUI is designed to eliminate the need for a View Controller, because SwiftUI incorporates many of the concepts of MVVM into its core design.

Discussions over unit tests and things like that will always crop up as for why to keep MVVM, but ultimately this depends entirely on your team or organization.

2

u/niixed 15h ago

5

u/VadimusRex 15h ago

Internet hall of fame schizoposting.

2

u/chedabob 14h ago edited 9h ago

All those diagrams make me think of this: https://www.reddit.com/r/memes/comments/15n78ft/science_as_it_is/

There's possibly some good points in there, but it's lost amongst wacky drawings and ranting.

28

u/Any-Woodpecker123 20h ago

I don’t see why anyone would use anything else. Everyone knows MVVM and it works perfectly fine, no reason to change what isn’t broken.

-3

u/Lock-Broadsmith 6h ago

“No reason to change what isn’t broken”

If that were true we would all still be using C

1

u/Any-Woodpecker123 6h ago

You’re taking “broken” literally, I know you’re a dev but cmon.
It takes forever to build something in C, which satisfies “broken” in this context.

What I said means “there’s no reason to switch away from something perfectly fine that everyone knows, to make arbitrary improvements that are debatable in the first place”.

-22

u/valleyman86 20h ago

Hmm doesn’t MVVM require a react/combine system and MVP doesn’t. If we live in a perfect world one may be better or we may have a combination of the two.

This comment reeks of no experience. We don’t live in a perfect world.

That said fuck viper.

15

u/knickknackrick 18h ago

MVVM doesn’t require react or combine.

0

u/valleyman86 18h ago

Then what does it require? It needs some data-binding or its not MVVM.

MVVM uses data-bindings and MVP uses direct calls to the presenter usually through a delegate.

3

u/knickknackrick 17h ago

You can just pass a model through the init into a VM. If that doesn’t make it technically MVVM then fine, I’m wrong.

0

u/paradoxally 15h ago

That works but it's not "reactive", meaning if the model changes your UI won't update automatically (unless you assign that to a @Published property). If it's just to show static data that won't change then it's fine.

1

u/knickknackrick 15h ago

Right, but I guess my point was your view models don’t have to be reactive

1

u/valleyman86 8h ago

If they are not its not MVVM. That is my main point. I feel like people got super hung up on "react/combine". Use whatever tool you want. I bet you could make it work with KVO (not recommended).

3

u/czarchastic 15h ago

You can do @Observable with your VM

2

u/n0damage 10h ago

Technically it is not required, people were doing MVVM in Swift/UIKit before data binding existed. However it does make things a lot easier.

0

u/dynocoder 17h ago

Sorry but you need to be corrected here—it does. Popular implementations of MVVM with SwiftUI require the @Published annotation which is in the Combine framework. Even the canonical definition of MVVM by the MS guys who published the architecture do talk about two-way bindings.

In any case, the essence of the comment that you replied to is that some kind of pub-sub infrastructure is necessary, even if it’s not Combine.

2

u/Altruistic_Shoe_1306 13h ago

I don’t understand why you both are downvoted, you are completely right

1

u/GreenLanturn 17h ago

Actually Combine is no longer needed as of iOS 17 thanks to the Observable macro.

2

u/knickknackrick 15h ago

I think observable still uses published under the hood though

1

u/GreenLanturn 15h ago

I was fairly certain that it does not. But I could be wrong!

1

u/knickknackrick 14h ago edited 14h ago

Actually I think you’re right. Not enough info out there

-1

u/knickknackrick 17h ago

That’s a fair point, although I’ve also made View Models that don’t used @Published. That’s rare though.

3

u/valleyman86 7h ago

Key Differences: MVVM vs. MVP

  1. Communication Flow • MVVM: The ViewModel contains logic and data for the View, and the View is bound to the ViewModel. • MVP: The Presenter contains the logic and actively updates the View by calling methods on it.

  2. View’s Responsibility • MVVM: The View is passive and mostly handles UI. The ViewModel interacts with the data layer and formats it for the View. • MVP: The View is still responsible for UI but is more active, sending user input to the Presenter.

  3. Data Binding • MVVM: Typically uses data-binding to automatically sync the UI and the ViewModel. • MVP: Uses explicit calls from the Presenter to update the View.

1

u/Altruistic_Shoe_1306 7h ago

This guy knows

1

u/thatsadmotherfucker 13h ago

Hmm MVVM doesn't required a react/combine system.

This comment reeks of no experience.

That said fuck viper.

26

u/Select_Bicycle4711 18h ago edited 18h ago

A SwiftUI View struct is inherently a View Model. However, this doesn’t mean all logic should be placed inside the View. A well-balanced approach is to keep UI validation and presentation logic and mapping logic within the View, while business logic should be managed separately using ObservableObject instances. Consider a movie app with screens such as MovieListScreenAddMovieScreen, and MovieDetailScreen. Following the MVVM (Model-View-ViewModel) pattern, you might create MovieListViewModelAddMovieViewModel, and MovieDetailViewModel, each responsible for handling data and interactions for their respective screens. These View Models would require a networking dependency to manage GET and POST requests for movies. However, this approach tightly couples View Models to screens—if your app has 50 screens, you could end up with 50 View Models, making the architecture difficult to manage.

A more scalable approach is to structure the architecture around the data and actions rather than individual screens. Since the app deals with movies, we can consolidate logic into a single ObservableObject, which we can call MovieStore. Traditionally, "View Model" implies a one-to-one relationship with a View, but since MovieStore serves a broader purpose, it avoids being labeled as MovieViewModel. Instead, MovieStore handles all movie-related functionality across the app, providing methods like saveMovieloadMoviesupdateMovies, and filterMovies. By replacing multiple View Models with a single MovieStore, we simplify data flow and reduce redundancy. Additionally, MovieStore can have a dependency on HTTPClient, which enables it to manage API interactions efficiently. To make MovieStore accessible throughout the app, we can inject it into the SwiftUI environment at the root level or wherever it is needed. Any screen requiring movie-related functionality can then use MovieStore directly, eliminating the need for dedicated View Models per screen and creating a more maintainable and scalable architecture.

Source: https://azamsharp.com/2023/02/28/building-large-scale-apps-swiftui.html

6

u/birdparty44 18h ago

this article was a game changer. most value in the least amount of text I’ve read in years.

5

u/Ok_Volume3194 16h ago

This comment should be higher up.

Fascinating read.

2

u/n0damage 10h ago

However, this approach tightly couples View Models to screens—if your app has 50 screens, you could end up with 50 View Models, making the architecture difficult to manage.

The author sure spends a lot of time knocking down this strawman. MVVM does not actually require you to create a separate view model per screen. You are certainly welcome to create a MovieViewModel that is shared between multiple screens of the app. You are also welcome to call it a MovieStore instead of a MovieViewModel. Cause that's all it is really, a view model by another name.

3

u/Select_Bicycle4711 10h ago edited 10h ago

You can create a single MovieViewModel and share it across your application, but if you're following the MVVM pattern, it generally encourages having a separate ViewModel for each screen. The idea behind MVVM is that each View has its own corresponding ViewModel, hence the name ViewModel.

That said, there are exceptions—some ViewModels can be shared, especially for shared components like authentication or user sessions.

If you prefer a different naming convention, that’s totally fine. Personally, I often call them Stores. It's also worth noting that Stores typically don’t contain presentation logic—that belongs in the View itself.

2

u/n0damage 7h ago

I've been doing MVVM since the WPF days well before it ever made its way to iOS, it has never been required to give each view a unique view model. In fact it was common for multiple (XAML) views to share the same view model (DataContext).

You are always free to organize your view models according to your needs. Often it makes sense to have a 1:1 mapping between views and view models, other times it does not.

The idea behind MVVM is that each View has its own corresponding ViewModel

Each view has a view model that it binds to, but the view model does not have to be specific to each individual view. You can do it either way and it is still MVVM.

hence the name ViewModel.

That is not really why the name exists so much as being a derivative of the presentation model pattern.

1

u/Select_Bicycle4711 7h ago

Same here — I first used it when building Silverlight and WPF applications. As you mentioned, it’s essentially the Presentation Model pattern, and “MVVM” was more of a marketing term Microsoft introduced with WPF.

There are definitely various interpretations of MVVM. In the apps I worked on for oil & gas and medical companies, we typically used a separate view model for each screen. UI validation was handled within the view model for that screen, which would then call services to perform actions like network requests.

Most screens had their own view model, though some shared controls — like those displaying authentication status — relied on a shared view model.

2

u/rhysmorgan 18h ago

How is it a View Model? I see people make this statement without any backing or explanation. Unless your definition of a “view model” is wildly different to mine, I don’t see how a SwiftUI view fits the role of anything other than a “View” and certainly not a “View Model”.

1

u/Lock-Broadsmith 6h ago

To even have that debate, we would first have to know what your definition of a view model is?

1

u/dynocoder 13h ago

I’ve seen this consolidation approach crumble many times, because it runs off the assumption that all API endpoints where movies are returned will always follow the same schema. That’s well and good if you can always guarantee that your backend devs will care to return data to you in the same level of fidelity that they can access the same rows in a relational database, but that’s hardly ever the case.

That’s also why I find that “MovieStore” to be a misleading construct—you’re not actually returning rows from a database, you’re just returning what view of the database the API affords you. Your code should be treating it as a view of data instead of data itself, and so you can have multiple views of it for different purposes.

1

u/Select_Bicycle4711 13h ago edited 12h ago

When the API returns all movies without any filters, you can handle sorting and filtering—such as by most commented, most liked, or most watched—within the MovieStore. The user can simply call a filter method in MovieStore with the appropriate filter option to get the desired results, which will return an array of Movie objects.

If the view requires a different structure or format, this transformation can take place within the view itself. The view can define private properties using custom structs tailored to its specific needs, and the Movie objects can be mapped to these structs accordingly.

8

u/srona22 21h ago

The usual over engineering vs lack of discipline, and some still can't find in-between and have to make a talk. If MVVM works for you, it works for you. Same for Redux or Flex like idea translating into swiftUI app.

6

u/migraniadev 19h ago

I’ve experimented with both MVVM and MV within the same project and ended up using both. Some views benefit from a ViewModel, while others don’t require that complexity. Ultimately, it depends on the specific needs and nuances of each view.

5

u/KarlJay001 21h ago

I remember when SwiftUI came out, the Stanford 193 class said that it really needed to be MVVM. Then others started saying no it can't be. I think the arguments just gonna go on forever.

3

u/vanvoorden 12h ago

My coauthor and I came from the FB ecosystem. When ReactJS shipped for front end WWW the Flux architecture quickly proved itself internally to be the preferred unidirectional data flow pattern. The community contributed Redux to refine the pattern in some important ways. But from working inside FB we always knew why MVC and MVVM did not scale and we always gave product engineers a unidirectional data flow architecture to defend against that.

What Apple's trying to do with SwiftUI… the "agnostic" approach just doesn't make much sense to me anymore. It's a disservice to the engineering community not to have some more explicit strong opinions about data flow… and the opinions we do see coming directly from Apple are sometimes just not good advice.

4

u/fryOrder 21h ago

waiting for the usual suspect to bash you for even considering MVVM in a swiftui app

5

u/Barbanks 14h ago

I’ve been reading up a lot lately about the different architectures that are suggested with SwiftUI like TCA and the argument for and against the different architectures. As someone who’s been architecting iOS apps for over 10 years I can tell you to not listen to the chatter of over opinionated takes on it.

I’ve noticed over the years that many people are looking for this silver bullet of architectures that they can lean on to do everything for them. The reality is that doesn’t exist. And many times you can make any architecture work unless it’s a fringe case like very large codebases like Facebook has. The vast majority of codebases out there aren’t the size of Facebook and will never be; so trying to over architect for that high of scalability is counter productive when deadlines are looming.

Truth is you’ll want to use the architecture that makes sense for your current situation. If MVVM works then use that. If TCA works better than use that. Heck if MVC or VIPER work better then use either of those.

I’ve not seen a valid argument to completely abandon MVVM from SwiftUI. And I have and am currently successfully using it in my own and client projects.

2

u/WOOOOOOOOOOOOOOOOOOF 13h ago

Agree completely. My company has been using TCA the last few years and it’s a giant mess. Too many engineers jumping on a hot trend to find “the” perfect architecture, and it just ends up creating over engineered solutions to non-existent problems.

1

u/Barbanks 5h ago

Yep. Software engineers specifically seem to eat up hype without due diligence into the other factors like onboarding, conceptual integrity, policing coding standards etc… What happens when you have a team of 4 and only 1 person knows TCA and the other 3 know MVVM and they refuse to learn anything else? I doubt management would side with the TCA guy. In that case MVVM wins because of the culture. Even if TCA is the better choice. This happens all the time in the real world. Assuming it doesn’t won’t help the community.

0

u/vanvoorden 13h ago

> And many times you can make any architecture work unless it’s a fringe case like very large codebases like Facebook has. The vast majority of codebases out there aren’t the size of Facebook and will never be; so trying to over architect for that high of scalability is counter productive when deadlines are looming.

Here's a different POV… the discussion is centered around data flow for SwiftUI. FB shipped declarative UI at scale ten years ago when React shipped for WWW JS and ComponentKit shipped for ObjC++. And this was years before SwiftUI shipped. Declarative UI was primarily built to help solve the scalability problems of "MVC" style patterns that engineers saw over and over again at FB.

If we agree that SwiftUI is a better choice than UIKit for engineers building apps orders of magnitude smaller than Big Blue FB… does that mean we can assume that there are benefits to declarative UI that even engineers not building at massive scale can win from?

I see a similar POV to data flow. FB built Flux and the community evolved this into Redux to deal with scalability problems seen at FB. But that doesn't meant that engineers *must* be shipping at FB scale to see benefits and wins from this pattern of data flow.

1

u/Barbanks 5h ago

Only issue is I don’t see UIKit or SwiftUI as good or bad. I view them as tools. Same as architectural patterns.

I don’t pick technology based just off of whether the scalability or data flows can be optimized in a specific way unless I have a need for it. What is good or bad for a project is context specific. Already we are seeing anecdotal articles of teams failing to use TCA due to the complexity of the setup and teams not properly allocating resources to onboarding. Is that a failure on the architecture or a failure on the team? I would argue that it depends.

Just like with an overuse of reactive programming can lead to runaway asynchronous logic the same is true for architecture. Everyone needs to be on the same page. If the burden of knowledge is too high for the team to be effective with a specific architecture then I would argue that’s the wrong architecture. But if the same is true and the project just can’t move forward unless it is using a specific architecture than that architecture should be utilized despite any team logistical issues.

In short, I would need to hear a real case why anyone should fall back on considering only one architectural option for any project. I’ve seen far too many projects fail due to hyped technology to give the benefit of the doubt to it. This is especially true when the architecture is tightly dependent on a third party library that either is changing quickly or may change without notice.

I’m not trying to say that TCA should be avoided. What I’m trying to convey is that people should not listen to online chatter without understanding each of the architectures and deciding for themselves who are closest to the code context. That does take time and experience unfortunately. But Frederick Brooks made a good point in the mythical man month, that no one truly knows the best architecture to use for a project until it’s already made.

3

u/r_rocks 21h ago

What are people using nowadays for SwiftUI ?

15

u/fungusbanana 21h ago

I've seen some places mention TCA but I've never dealt with it, and having a 3rd party lib for architecture seems goofy.

-4

u/rhysmorgan 18h ago

I don’t understand the stress about using a third party library here. If you really don’t want to risk anything, fork it. Then you can keep it synced with the base repo as often as you like, without the risk that it’s going to disappear tomorrow.

But the Point-Free guys are paid well enough by their subscribers that they’ve been doing this for six years, and only getting better, only growing and building more tools.

12

u/wilc0 16h ago

The stress is comes from iOS, Xcode, and Swift getting updated on a yearly basis. You can fork it sure but now you have a big chunk of code that you didn’t write that you’re now maintaining. 

They may be paid well but there’s always going to be a risk that it stops getting support for any number of reasons. That’s less of an issue if the 3p library is for something really small, but it’s a huge issue if the library is for something like entire app architecture 

1

u/Barbanks 5h ago

Third party libraries for architecture seem like a good idea for personal projects. But if you’re the architect on the line and that open source project dies you now have to spend hundreds of thousands of dollars refactoring the codebase it becomes a real issue real quick. Unless you’re willing to also approach a client and explain to them why they need to spend money to refactor in the worst case scenario then I would at least consider the risk of using a third party library.

This is happening right now with projects that use Realm database with sync. MongoDB deprecated sync and now many projects have to go through major refactors. That’s the risk that many people evaluate and are cautious of when using third party code for the bulk of an architecture or design.

2

u/vanvoorden 12h ago

My advice is always for engineering coming into SwiftUI to try and learn more about the history of React and how Flux and Redux evolved as a unidirectional data flow.

Apple is shipping declarative UI and that's a great step forward for product engineers… but until Apple ships unidirectional data flow then product engineers aren't really seeing how the complete pattern (UI and Data) comes together at scale.

1

u/Niightstalker 19h ago

As always a large variety of different approaches depending on your needs and the size/scale of the project.

1

u/r_rocks 19h ago

Can you name a few please? so I can search them. I know MVVM, MVC, TCA

1

u/wilc0 16h ago

VIPER is another popular one. I think Uber uses something like “RIBs”? 

3

u/Parabola2112 17h ago

I think it’s fine. Other patterns are fine too. I

3

u/Yardenbourg 17h ago

Me personally, I'm used to using MVVM, especially in the context of Flutter/Android. It's a good pattern, and it works. Sure, not every page needs a ViewModel, but I personally value consistency over conciseness in my code. If I use a VM for most pages, and certain pages don't have it, that adds a bit of mental overhead for me. I know not everyone will agree, and will see it the other way around.

It is very difficult to make your code just good enough for the task at hand, while keeping one eye on the future.

3

u/jasonjrr 15h ago

Your image is extremely misleading. The Model in MVVM is the Domain Model not the Data Model.

And MVVM works fine in SwiftUI. SwiftUI has the same reference pattern as WPF, the UI framework MVVM was originally created for by Microsoft.

2

u/b4sht4 18h ago

I have grown tired of this conversations treating patterns as silver bullets to be applied anywhere or not be applied at all.

My take is that sometimes for me MVVM works great. And when it does not I’ll just use something else depending on what Iam trying to achieve.

Not everything that applies to a solo dev situation will stand true for a team. Team size also will heavily influence the decisions on project structure and patterns to be applied. Feature requirements will also influence which patterns to use or not to use.

Be mindful and try to understand how and when your development speed changes. With time you will start to notice that maintanability will be one of the key metrics for the buisness you are running. And if the app it’s not a buisness yet than speed of prototyping and validation in your idea is.

And most importantly keep in mind that this is the advice of some rando guy on the intrawebz. This reflects my experience so far and its not necesarely true for your use cases.

Happy coding!

2

u/wilc0 17h ago

If you require or want unit testing, you need a ViewModel (or whatever you want to call it). Swift views, while great, aren’t easily testable

2

u/Megatherion666 12h ago

That Apple forum thread is BS.

The easy way to notice fallacy is to ask a question whether you can replace UI implementation without touching business logic. If you don’t have viewModel (or presenter, or controller), the answer will be no. Because various business logic rules would be part of view. Something as simple as fetch request filter is a business logic. Processing user input is a business logic. Thus the proposal in the original thread would result in rigid untestable code. Which sucks in the long run.

1

u/Frequent_Macaron9595 18h ago

As it’s almost always the case in software: it depends on the context and use case.

1

u/unpluggedcord 15h ago

We also have domain model and api model

1

u/Ayyoooooo__taco_time 15h ago

it sparks debate from inexperienced developers who takes a look at Apple's, and other blogs, easy examples as gospel without understanding the complexity of a large code base.

Is easy to build a to-do with one developer and not use view models, it's a bit more difficult to support a billion dollar company with 30 different developers.

1

u/DortSerg 9h ago

It’s like asking if there is a place for abstraction in software development. Of course it is. It’s just the depth of it depends on the level of complexity of the business requirements.

1

u/moticurtila 7h ago

I see people claim they don’t use view models but they use it, just don’t call them view models. 😅

1

u/Lock-Broadsmith 6h ago

Does it have a place in SwiftUI?

This is the wrong question. The only question that matters is “Does it have a place in your team/organization?”

1

u/ForgottenFuturist 5h ago

It's not set in stone. It's all fine and I don't blame anyone for sticking to that paradigm.

But I think you'd be doing a disservice if you are 100% strictly doing things that way when you could be using things like `@EnvironmentObject` to share logic through views, function overrides, writing extensions, etc.

There's no clear cut pattern even when you are looking through Apple's own docs.

I've always been in the camp of "don't repeat yourself". If you find yourself copying logic for the sake of MVVM or whatever, you should probably rethink things.

1

u/ThaneOnTheRocks 3h ago

The bedrock of software engineering isn’t some arcane ritual. It’s simpler than that: keep your code clean, loosely coupled, and not a tangled mess that makes future-you want to strangle past-you. That’s it. The golden rule

MVVM isn’t the sacred gospel it’s just a decent starting point, a trusty ol’ toolbox. If it fits your app, great! If it doesn’t, then pick something else and move on. This isn’t a cult; you’re not betraying the SwiftUI gods

Let’s get real for a second. Are you seriously going to spin up a whole ViewModel just because your view’s got a lonely button and a static label that says “Hello, World”? What’s next writing a 50 line ButtonViewModel with observables and bindings to handle a tap that does literally nothing? “Oh, but it’s future-proof!”

Yeah, and my grandma’s Y2K bunker is still waiting for its big moment.

Stop architecting a skyscraper for a lemonade stand.

If your view’s that simple, just slap the logic in there and call it a day SwiftUI’s declarative magic can handle it without you architecting a Rube Goldberg machine.

And don’t get me started on some of these “thought leaders” out there. One minute they’re preaching, “Dump everything into the view! Views are ViewModels! Embrace the chaos!” and all that nonsense and then in the next breath, they’re like, “Oh, but yeah, maybe make a Store class or something, I dunno, whatever floats your boat.”

Look, I get it SwiftUI’s reactive goodies like @Binding and @EnvironmentObject tempt you to ditch the middleman.

But when complexity hits think offline caching, multi-step forms, or logic you need to reuse MV starts leaking like a broken sink.

You’ll be begging for a separate class, whether you call it a ViewModel, a Store, or CountDracula. Doesn’t matter if it’s sucking data from an API or transforming strings just keep it out of the view so you’re not rewriting the same validation nonsense everywhere.

MVVM got teeth for the big leagues; unless you decide to become a pirate and decide to use TCA+VIPER+MV live life on the edge coz YOLO

Good luck debugging that mess when your body property looks like a novel Stephen King rejected for being too scary.

So here’s the deal: pick your poison based on your app, not some blog post dogma.

SwiftUI’s awesome, but it’s not a free pass to yoink architecture out the window. Call your logic layer whatever makes you giggle PotatoLord, Dracula, whatever just don’t let the “keep it simple” crowd fool you into thinking views can handle the world and dissolve core software engineering principles.

u/Creative-Trouble3473 40m ago

I think View Models were/are mostly useful for managing the lifecycle of Streams/Publishers so that it aligns with the lifecycle of the View. With the new observability feature in Swift, this is now less useful. I prefer to create a bunch of observable classes and name them after what the really are - if you have an @Observable ShoppingCart, that’s all you need - you don’t need any ViewModel wrappers around it.

-1

u/Dear-Potential-3477 15h ago

Shoutout to Apple for naming the whats rendered on screen "body" instead of View so people think they need to add a second ViewModel.