Stop using MVVM for SwiftUI

Don’t over-engineering! No suggested architecture for SwiftUI, just MVC without the C.

On SwiftUI you get extra (or wrong) work and complexity for no benefits. Don’t fight the system.

Post not yet marked as solved Up vote post of Appeloper Down vote post of Appeloper
7.5k views
Posted by
Appeloper
Reply

  • Thank you, very helpful. Especially enjoyed the big fat mess as the end 😂

    —
    kp2485

  • 1/N Thanks for writing this post! I have written many articles regarding SwiftUI and MVVM, I have written books and even created courses on SwiftUI and MVVM. But each time I implemented a solution in SwiftUI and MVVM I felt not comfortable. The main reason was that I was always fighting the framework. When you work on a large application using MVVM with SwiftUI and you want to share state then it becomes extremely hard.

    —
    azamsharp

  • 2/N The main reason is that you cannot access EnvironmentObject inside the view model. Well, you can pass it using a constructor but then it becomes pain to do it again and again. And most of the time, you end up getting confused that who is managing the state. I ran into this scenario multiple times and I had to take alternate routes to resolve this problem. One thing to note is that React and Flutter (as original poster said) does not use MVVM pattern. React uses context or Redux and Flutter

    —
    azamsharp

Replies

Sorry, the examples are not testable? Not clean? Today developers are obsessed with tests and other ugly thinks. I see projects delayed with lots problems because devs today want to be SOLID and testable.

Agile, SOLID and over testing works like a cancer for development teams.

Sorry but if people want to be complicated they should move to Android or other platforms.

Posted by
Appeloper
Post not yet marked as solved Up vote reply of Appeloper Down vote reply of Appeloper

  • Thank you!!! I've felt like a lone crazy person for years advocating against unit testing. In my experience they very rarely (or actually never) catch bugs, cost a lot of time to maintain, and also create ugly architecture. The obsession with number of lines of code covered is especially awful.

    Save unit testing for tricky algorithms, leave it out of simple view/model interactions!

    —
    tandersen

  • Out of interest what test strategy would to apply for a general iOS project? Can you still test most things using MV or you don't bother with unit tests and use UI testing / integration?

    I'm coming from a predominantly .NET background to iOS and still learning SwiftUI - I did groan when I saw MVVM mentioned in more 'advanced' courses, I remember WPF days!

    —
    mjharper
Add a Comment

This is software engineering! KISS (Keep It Simple)

This is SOLID (complicated and obsessed people call this clean…. are you kidding?!)

Posted by
Appeloper
Up vote reply of Appeloper Down vote reply of Appeloper
Add a Comment

Remember:

  • Avoid sacrificing software design for testability
  • Automated tests didn’t ensure a quality product

Last years I see a correlation between the increased reliance on automated testing and the decline in quality of software.

A real project that failed and I fixed, one of many problematic projects!

Companies must be careful with devs obsessed with SOLID principles and testability.

In 20 years of software engineering I've never seen soo bad & inefficient developers than in last years. In case of iOS there are very bad developers that come from Web or Android. They fight the system with other platforms concepts and testability talk.

Posted by
Appeloper
Up vote reply of Appeloper Down vote reply of Appeloper

  • OMG, I would love to work with you.

    —
    kafran
Add a Comment

I've seen a lot of questions about MVVM (in general and about testability) unnecessary limitations & problems in WWDC22 SwiftUI digital lounge.

I think developers should start understand & think SwiftUI, instead another platform's strategy.

Apple patterns has been used very successfully by Cocoa developers for decades. It just works, and you don't have to fight it. Jumping into more complicated patterns is not a good approach for developers. Your self, your team, your company and your users will thank you!

Posted by
Appeloper
Up vote reply of Appeloper Down vote reply of Appeloper
Add a Comment

I fail to understand how a post like this is being upvotes while it encourages a paradigm SwiftUI itself isn’t based on. Speaking to MVU and Elm patterns is different than identifying “MVC without the C”..

Posted by
TheCodingArt
Post not yet marked as solved Up vote reply of TheCodingArt Down vote reply of TheCodingArt

  • Can you give any arguments for "a paradigm SwiftUI itself isn’t based on", Appleloper had given us multiple slides directly from Apple, showing that the architecture Apple uses and has in mind with SwiftUI is not necessarily MVVM but something else. Elm pattern is effectively model-view pattern but it doesn't specify other things like data flow(property wrappers like @ObservableObject, @Binding etc.), or navigation(wwdc22). So it feels like Elm pattern is only part of broader "Apple pattern".

    —
    NiteOwl

  • @NiteOwl, this is really not true, apple itself has begun integrating VM in some example projects or documentation, not to mention that all of the example that the poster keeps spamming on all possible Apple forums and channels are extremely trivial. I tend to not trust who speech with so much confidence, but just look at the project he claims he improved, it is definitely a terrible one to begin with, easy to improve it in any way.

    —
    jalone

  • pt2. As soon as you start having complex UI logic in place (eg: an animated chatbot, or an interactive tutorial) the last thing you want is to mix it up with business logic, network or db calls and what not. Not to mention that in more and more fields of app development (health, finance, banking, etc) testing is an obligatory and regulated component you cannot avoid even if you think it is bad practice (??).

    Each project has it's own requirements and therefore architecture.

    —
    jalone
Add a Comment

WWDC 2022 - Data Essentials in SwiftUI

Posted by
Appeloper
Up vote reply of Appeloper Down vote reply of Appeloper

  • I'm sorry but this session is not WWDC 2022 but 2020.

    —
    kyungkoo_kang

  • Correct, my fault, sorry. It’s 2020 session when SwiftUI bring @StateObject.

    —
    Appeloper

  • Is this the same approach as vue + vuex / pinia? local state is in the views and more complex / shared state you add to a store

    —
    mjharper

The model is composed by Data Objects (structs), Service Objects (providers, shared classes) and State Objects (observable objects, “life cycle” / “data projection” classes). We should use the state objects for specific (or related) data and functionality, not for screen / view, as they should be independent from specific UI structure / needs, When needed we can share then in view hierarchy.

Remember (using state objects in views):

  • StateObject - strong reference, single source of truth
  • EnvironmentObject / ObservedObject - weak reference

Also (when async calls needed):

  • Define state objects (or base class) as MainActor to avoid warnings and concurrency problems
  • Define state object tasks as async, e.g “func load() async”, because for some situations you need to do other jobs after data load completed and async is more simple / sequencial than checking the “phase” (.loaded) using onChange(of:)

Big apps can have more models. This is just an example:

Posted by
Appeloper
Up vote reply of Appeloper Down vote reply of Appeloper
Add a Comment

This message is from the original poster of this post. If you get this message please contact me on Twitter at @azamsharp. I am writing a post about the same topic and your help will be really appreciated.

Posted by
azamsharp
Up vote reply of azamsharp Down vote reply of azamsharp
Add a Comment