Stop using MVVM for SwiftUI

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.

This is software engineering! KISS (Keep It Simple)

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

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.

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!

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

WWDC 2022 - Data Essentials in SwiftUI

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:

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.

Isn't this example of MV fine until you start expanding, for example if you wanted to select a Product in the List and access this state from multiple views, you could put this state on the Product object or would you put the Product you selected on a state object?

Again, you don’t need a middle layer, just your model! Everything becomes easy, composable and flexible. And yes! You can do Unit / Integration tests.

UI = f(State) => View = f(Model)

SignIn

// State (shared in view hierarchy), part of your model
class Account: ObservableObject {
    @Published var isLogged: Bool = false

    func signIn(email: String, password: String) async throws { ... }
}

// View
struct SignInView: View {
    @EnvironmentObject private var account: Account

    @State private var email: String
    @State private var password: String

    // Focus, error state

    var body: some View { ... }

    // Call from button
    func signIn() {
        // Validation (can be on model side)
        // Change error state if needed

        Task {
            do {
                try await account.signIn(email: email,
                                         password: password)
            } catch {
                // Change error state
            }
        }
    }
}

SignUp

// Data (Active Record), part of model, can be an ObservableObject if needed
struct Registration: Codable {
    var name: String = ""
    var email: String = ""
    var password: String = ""
    var carBrand: String? = nil
    
    func signUp() async throws { ... }
}

// State (Store), part of model
class CarBrandStore: ObservableObject {
    @Published var brands: [String] = []
    
    // Phase (loading, loaded, empty, error)

    func load() async { ... }
}

// View
struct SignUpView: View {
    @State private var registration = Registration()
    @StateObject private var carBrandStore = CarBrandStore()
    
    // Focus, error state
    
    var body: some View { ... }

    // Call from button
    func signUp() {
        // Validation (can be on model side)
        // Change error state if needed

        Task {
            do {
                try await registration.signUp()
            } catch {
                // Change error state
            }
        }
    }
}

Yes it's fine for small indie apps. Putting logic in a Model is absolutely ridiculous to me having Observed and State Objects provided by Apple and simply ignoring them because you don't like ViewModel term is just crazy in my opinion. Whatever works for you mate, I like my code modular and testable.

ok so If I am getting correctly then Account will have code for validation, network call, caching, routing, etc...

// State (shared in view hierarchy), part of your model
class Account: ObservableObject {
    @Published var isLogged: Bool = false

    func signIn(email: String, password: String) async throws {
     // VALIDATION CODE ****1
     // NETWORK CALL (we will have shared network object) ****2
     // PERSISTENT (we will have shared persistent object) ****3
     // ROUTE TO NEXT SCREEN (we will have global navigator or screen router) ****4
}
}

What we are achieving by giving so much responsibility to Account model.

Instead can't we just go with simple with SignInViewModel, also Validation, Persistency and Routing will not be tight together in Account.

See what I am thinking, and let's justify which one is better.

class SignInViewModel {
    func signIn(email: String, password: String) async throws {
     // NETWORK CALL (we will have shared network object) ****2
}
}

// View
struct SignInView: View {
    @EnvironmentObject private var account: Account

    @State private var email: String
    @State private var password: String

    var body: some View { ... }

    // Call from button
    func signIn() {

        // WE CAN CALL VALIDATION UTILITY FROM HERE ****1

        Task {
            do {
                try await signInViewModel.signIn(email: email, password: password)

              // WE CAN CALL PERSISTENT UTILITY FROM HERE ****3

             // THEN ROUTER CAN ROUTE TO NEXT VIEW  ****4

            } catch {
                // Change error state
            }
        }
    }
}

Model layer

class MyWebService {
    static let shared = MyWebService()
    
    // URLSession instance / configuration
    // Environments (dev, qa, prod, test / mocks)
    // Requests and token management
    
    var token: String? = nil
    
    func request<T>(/* path, method, query, payload*/) async throws -> T { ... }
    
    func requestAccess(username: String, password: String) async throws { ... }
    func revokeAccess() async throws { ... }
}

// Other names: User, UserStore, CurrentUser, ...
class Account: ObservableObject {
    @Published var isLogged: Bool = false
    @Published var error: Error? = nil
    
    struct Profile {
        let name: String
        let avatar: URL?
    }
    
    @Published var profile: Profile? = nil
    
    enum SignInError: Error {
        case mandatoryEmail
        case invalidEmail
        case mandatoryPassword
        case userNotFound
        case userActivationNeeded
    }
    
    func signIn(email: String, password: String) async {
        // Validation
        if email.isEmpty {
            error = SignInError.mandatoryEmail
            return
        } else if email.isEmail {
            error = SignInError.invalidEmail
            return
        }
        
        if password.isEmpty {
            error = SignInError.mandatoryPassword
            return
        }
        
        // Submit
        do {
            try await MyWebService.shared.requestAccess(username: email,
                                                        password: password)
            isLogged = true
            error = nil
        } catch HTTPError.forbidden {
            error = SignInError.userActivationNeeded
        } catch HTTPError.notFound {
            error = SignInError.userNotFound
        } catch {
            self.error = error
        }
    }
    
    func signOut() async {
        // Ignore any error
        try? await MyWebService.shared.revokeAccess()
        isLogged = false
    }
    
    func loadProfile() async {
        do {
            profile = try await MyWebService.shared.request(...)
            error = nil
        } catch {
            self.error = error
        }
    }
}

View layer

@main
struct MyApp: App {
    @StateObject var account = Account()
    
    var body: some Scene {
        WindowGroup {
            Group {
                if account.isLogged {
                    TabView { ... }
                        .task {
                            async account.loadProfile()
                        }
                } else {
                    SignInView()
                }
            }
            .environmentObject(account)
        }
    }
}

struct SignInView: View {
    @EnvironmentObject var account: Account
    
    @State private var email: String = ""
    @State private var password: String = ""
    
    // Text fields, button, error exception
    var body: some View {
        ScrollView { ... }
    }
    
    func signIn() {
        Task {
            await account.signIn(email: email,
                                 password: password)
        }
    }
}

How some developers, obsessed by testability & SOLID principles, think “separation of concerns”, making something simple, ..complex, problematic, expensive.

Model layer

class MyWebService {
    static let shared = MyWebService
    
    // URLSession instance / configuration
    // JSONDecoder/Encoder configuration
    // Environments (dev, qa, prod, test / mocks)
    // Requests and token management
    
    var token: String? = nil
    
    func request<T: Codable>(/* path, method, query, payload*/) async throws -> T { ... }
    
    func requestAccess(username: String, password: String) async throws { ... }
    func revokeAccess() async throws { ... }
}

struct Product: Identifiable, Hashable, Codable {
    let id: Int
    let name: String
    let description: String
    let image: URL?
    let price: Double
    let inStock: Bool
}

class ProductStore: ObservableObject {
    @Published var products: [Product] = []
    
    enum Phase {
        case waiting
        case success
        case failure(Error)
    }
    
    @Published var phase: Phase? = nil
    
    func load() async {
        do {
            phase = .waiting
            products = try await MyWebService.shared.request(path: “products”)
            phase = .success
        } catch {
            phase = .failure(error)
        }
    }
}

View layer

struct ProductList: View {
    @StateObject var store = ProductStore()

    var body: some View {
        List { ... }
            .task {
                await store.load()
            }
            .navigationDestination(for: Product.self) { product in
                ProductView(product: product)
                // (--- OPTIONAL ---)
                // Only if you need to make changes to the store and that store its not already shared
                // ProductView(product: product)
                //    .environmentObject(store)
                // (--- OR ---)
                // ProductView(product: product, store: store)
            }
    }
}

struct ProductView: View {
    var product: Product
    // (--- OR ---)
    // If you make changes to the product
    // @State var product: Product    

    // (--- OPTIONAL ---)
    // Only if you need to make changes to the store and that store its not already shared
    // @EnvironmentObject private var store: ProductStore
    // (--- OR ---)
    // @ObservedObject var store: ProductStore
    
    var body: some View {
        ScrollView { ... }
    }
}