Prompted by a Fireside Swift episode on SOLID principles and the arrival of Core Data in the 100 Days of SwiftUI course, I reflect on when architecture should enter an iOS developer’s toolkit. Drawing on a long-standing habit of wrapping external dependencies for easy replacement, I conclude that scalable code suits real apps but not learning—which is likely why Paul Hudson defers architecture until later in the course...
This is a follow-up to my earlier simple MVVM example, correcting my use of @ObservedObject for a view model created inside a SwiftUI view. Because SwiftUI can recreate views at any time, I explain that @StateObject is the correct wrapper in that situation, with @ObservedObject reserved for objects passed down from parent views, and I link to Apple’s documentation and other explanations of the difference...
I explain the MVVM architectural pattern using a simple SwiftUI light bulb toggle app as an example. I walk through the Model, View Model, and View components, how they connect through ObservableObject and @Published/@StateObject, and why separating data from the interface matters. I’ve made the source code available on GitHub...
After watching part of a video by Emmanuel Okwara, I explain my new understanding of how MVVM differs from MVC: in MVVM the ViewModel doesn’t manipulate the View directly, it just broadcasts changes and lets the View update itself, which fits SwiftUI’s declarative style. I raise an open question about what constitutes a View in MVVM and plan to build a minimal MVVM app as a practice project...
