Good topic to discuss further. Another video on this view-only approach with code examples would be nice 👍

For smaller MVVM projects, I use something I borrowed from Paul Hudson and put the ViewModel inside the View. *taps forehead* It's a compromise between the two approaches, but still keeps the viewmodel code directly out of the view code.

It seems so much easier to read and write the code when dropping the view model, and just using service classes.

Could you provide a video with examples in cases where you think it reduces complexity to musing view only or shared instances? 😄🙏🏻

Thank you for this insightful video. I'm not sure using view-only completely removes testability. Don't you think there's still a way to test the properties and functions of the struct? At the end it's just a normal struct with a special body property? There's also the ViewInspector library for unit testing SwiftUI views, which looks very promising in covering the testability of view-only architectures.

To be really honest, I don't think these kind of architecture is just for small app/prototyping, they really could work in a bigger project since SwiftUI views are meant to be small and cheap. The only thing we need to improve to make this architecture (that you call "View-only") is make it testable, corporate people love talking about their code-coverage even if 90% of the tests are total bullshit because they mock everything and in the end nothing is tested. Seriously, I've worked in a company that we had a lot of tests like this: "sut.response = mock(); sut.request().response == mock()". Anyways, I'm now in another company and I'm facing a similar problem, we are building a POC and the guy I'm working with wants to follow the Bible of Uncle Bob and that's pissing me off. Sorry for the vent in those last sentences, it's just that I'm full of people making complex stuff when it shouldn't be.

Flo, do you have any videos showing examples of View-Only?

I agree for simple apps, but some functionality is not even possible to do in the view file. I use hybrid, view models only for main screens of the app.

I always like to write my projects "future proof". Who knows, maybe it's successful and then you have to expand on it. I prefer MVVM. Yes, sometimes you have to write a VM class just for 2-3 properties, but in the end, it's just a few additional lines of code so it's not that big of a deal.

The MVVM crowd didn't bother to learn that the View struct plus modifiers property wrappers is equivalent to a view model object already so they don't need another one. I think they also don't know that SwiftUI diffs the hierarchy of View structs to create/update/remove UIView/NSView objects.

🎉 I congratulate you for having the courage to express your opinion even though you knew it was unpopular and that probably many people do not agree because is not that academic. I believe many times we use all sorts of architectures because we are simply used to and we feel kinda unprofessional if we do things simply, without any fancy pattern. You’ve highlighted a core idea that no architecture is bulletproof and we shouldn’t be scared of taking unpopular decisions in projects as long as they’re justified. I very much share the same thoughts.

How to call a pattern, when you're sticking to MVVM for actual app screens, but keep it to MV for simpler views? And also largely use service classes, because they are even better solution for unit testing?

Great video! I concur with your point that in smaller projects, particularly when working alone, strict adherence to a specific architecture may not be necessary. I would also advise having as testable and clean code as possible for bigger and more serious projects. The advantages of Core Data and View-Only are one of the reasons I don't like Core Data for larger projects because of the added complexity and overhead required to write scalable code. For my own project, I have chosen to use MVVM, even in the early stages, as I am looking at the project as a start-up business with potential to expand the team in the future. By using MVVM and learning best practices from the start, I aim to avoid technical debt and establish strong foundations for future development.

Is a good point find your own development style, thanks for the video

do I feel a new "view only" playlist coming up...? :) it be greatly appreciated. I do agree with the points u made there

Makes sense. If your service classes are already tested I would argue why then introduce a ViewModel for the sake of wanting more testing to happen

If you think MVVM adds complexity, then try VIPER out 😂

mvvm is just toxic with swiftui, it ruins your code

5:59 I am sorry, but I have done this custom init to View Model many times, and what I have found out (as far as I remember) is that you can not use @StateObject, but have to use @ObservedObject instead. Unless there is some work around possible to make it work with @ObservedObject, which I do not know about

Nice Video! MVVM is a cool pattern, because, if I edit the View, then I have only the view at the file and for logic the same. But SwiftUI also has cool features for writing logic in the view struct and with extension I also can write functions and View separate. I think with Swiftdate is View-Only much better as CoreData and View-Only. Because of this framework I try to use no Viewmodel in next projects for iOS 17 and macOS 14. With View-Only I can keep the lines and structure of the project small and simple. But if I know, I will testing the code or I use logic for backend, the better or only way is to use a viewModel or service classes. Both architectures are good and have advantages and disadvantages. I like the words from steve jobs. Another reason for me to write logic in the view struct is this thinking and the power of minimalism.🤏 (I hope, these sentences are understandable. Normally I speak german and my english is not perfect 😅.)