MVVM Architecture in iOS Apps

# CHAPTER 17

MVVM Architecture in iOS Apps #

1. Introduction #

2. Learning Objectives #

• Define the roles of the Model, the View, and the ViewModel.

• Create a class conforming to the ObservableObject protocol.

• Broadcast data changes using the @Published property wrapper.

• Instantiate and persist ViewModels using @StateObject.

• Separate business logic entirely from visual rendering code.

3. The MVVM Trinity #

1. 1. Model: The raw data structure (e.g., struct User). It does nothing but hold data.

1. 2. ViewModel: The brain (a class). It holds the data array, fetches it from the internet, and performs all logic. It prepares the data for the View.

1. 3. View: The face (the SwiftUI struct). It has zero logic. It simply asks the ViewModel for data and draws it on the screen.

4. Step 1: The Model (The Data Shape) #

import Foundation

// MODELS are almost always simple Structs.
struct User: Identifiable {
    let id = UUID()
    let username: String
    let followers: Int
}

5. Step 2: The ViewModel (The Brain) #

import Foundation

// VIEWMODELS are always Classes!
class UserViewModel: ObservableObject {
    
    // The View will monitor this array.
    @Published var users: [User] = []
    
    // An example of "Business Logic" extracted away from the UI.
    func fetchFakeData() {
        // Pretend we are downloading this from the internet...
        let downloadedUsers = [
            User(username: "Alice_Dev", followers: 1500),
            User(username: "Bob_Codes", followers: 20)
        ]
        
        // Updating the @Published variable triggers the UI to redraw instantly!
        self.users = downloadedUsers
    }
    
    func addFollower(to index: Int) {
        // Complex logic handled purely in the ViewModel!
        let oldUser = users[index]
        let newUser = User(username: oldUser.username, followers: oldUser.followers + 1)
        users[index] = newUser
    }
}

6. Step 3: The View (The Face) #

import SwiftUI

struct UserListView: View {
    // We instantiate the Brain! 
    // @StateObject ensures the class is kept alive in memory.
    @StateObject private var viewModel = UserViewModel()
    
    var body: some View {
        NavigationStack {
            List(viewModel.users.indices, id: \.self) { index in
                HStack {
                    Text(viewModel.users[index].username)
                    Spacer()
                    Text("\(viewModel.users[index].followers) followers")
                        .foregroundColor(.gray)
                    
                    Button("Follow") {
                        // The View does ZERO math. It just asks the ViewModel to do it!
                        viewModel.addFollower(to: index)
                    }
                    .buttonStyle(.bordered)
                }
            }
            .navigationTitle("Users")
            // When the screen appears, ask the Brain to fetch the data!
            .onAppear {
                viewModel.fetchFakeData()
            }
        }
    }
}

7. @StateObject vs @ObservedObject #

• @StateObject: Use this EXACTLY ONCE when you are *creating* the ViewModel from scratch (= UserViewModel()). It tells SwiftUI to own and protect this class in memory.

• @ObservedObject: Use this if a Parent View created the class, and is *passing* it down into a Child view. If you use @ObservedObject to create a class from scratch, SwiftUI might randomly delete it during a render cycle, causing massive bugs!

8. Visual Learning: MVVM Flow #

[ The View (UI) ]
  |-- (Button Click) --> Calls viewModel.fetchData()
  
[ The ViewModel (Brain) ]
  |-- Executes networking logic.
  |-- Retrieves raw [ Model ] data.
  |-- Updates @Published var users.
  |-- (Radio Broadcast!) --> "Hey View, I updated!"
  
[ The View (UI) ]
  |-- Hears the broadcast.
  |-- Redraws the <List> with the new data!

9. Common Mistakes #

• Putting Logic in the View: If you have an if / else statement inside a Button action that checks a user's password length, performs an MD5 hash, and filters an array... your MVVM architecture has failed. The Button action should literally just be viewModel.loginPressed(). All that complex code belongs in the ViewModel file.

• Forgetting @Published: If you add an array to a ViewModel, but forget the @Published wrapper, the ViewModel will update its internal data perfectly, but it won't broadcast the change. The View will sit there frozen forever.

10. Best Practices #

• Folder Structure: In Xcode, you should create three distinct folders (Groups): Models, Views, and ViewModels. Keep your files strictly organized. User.swift goes in Models. UserViewModel.swift goes in ViewModels. UserListView.swift goes in Views.

11. Exercises #

1. 1. Create a Model struct Product.

1. 2. Create an ObservableObject class ProductViewModel containing a @Published var products = [Product]() and a method addProduct().

12. Coding Challenges #

13. MCQ Quiz with Answers #

14. Interview Questions #

• Q: Describe the architectural flow of MVVM. How does the ObservableObject protocol combined with @Published properties facilitate the reactive binding between the ViewModel and the View?

• Q: A developer uses @ObservedObject private var viewModel = MyViewModel() inside a view. Why is this structurally dangerous compared to @StateObject? What will eventually happen during a complex view lifecycle?

• Q: Explain why "Massive View Controller" syndrome was so prevalent in legacy UIKit development, and how SwiftUI's declarative nature combined with MVVM explicitly prevents it.

15. FAQs #

16. Summary #

17. Next Chapter Recommendation #