Matteo | Swift, iOS, Best Practices

Are architectural patterns really that different from each other? In my new article, I argue that they are not, the same way buildings rest on common principles. I take apart the VIPER pattern and show the parallels that emerge with MVVM when you consider the role of each layer rather than its name. Link in the replies.

When it comes to architectural patterns for SwiftUI, a common yet unhelpful answer is “it depends.” After many years of research, teaching, and practical implementations, I disagree with that answer. While implementation details often differ, there are architectural components that any software application requires. Read what they are here: matteomanferdini.com/mvvm-vs-viper/…

Online articles, books, and courses rarely approach SwiftUI development from a structural perspective. App architecture is always an afterthought, and many developers get bad habits. I wrote this guide to correct those bad habits. I have been teaching these best practices for years and noticed that many experienced developers don't know them. In fact, at the beginning of my career, I didn't know them either and made most of the mistakes I now see in many apps. matteomanferdini.com/swiftui-app-ar…

Value-destination navigation links in SwiftUI operate on types. However, they remain purely declarative until we need to inspect data to make a navigation decision, introducing non-UI logic into views and creating several architectural problems. Find out what they are here: matteomanferdini.com/mvvm-coordinat…

MVVM has been used by numerous developers for over two decades on various platforms, including iOS. However, some argue against MVVM in SwiftUI, stating that: 🔵 It’s the current year, and you should not use outdated design patterns. 🔵 View models make your code harder and offer no benefits. 🔵 View models conflict with Apple’s frameworks. 🔵 Our Apple overlords allegedly don’t want you to use MVVM. This leaves many wondering whether they should use view models or abandon them in favor of new patterns, such as MV. I answered all those objections and others here: matteomanferdini.com/swiftui-viewmo…

When stored properties are the only way to pass data to a view, we must use nested stacks to arrange them and optionals to avoid unnecessary parameters in initializers. It can be time-consuming to handle SwiftUI’s layout and determine the correct modifiers and spacing to align views perfectly. Passing a whole model type reduces the number of stored properties, but tightly couples the view and model layers, making views less reusable and harder to preview. Read more here: matteomanferdini.com/swiftui-views/…

@matthewmorek My point also stands, as I addressed all these in these in the linked article. I made sure to ask everyone here to list every criticism before I wrote it, to make sure I considered everything.

you’re right. there's no formal “M-V pattern” spec. wrong terminology on my part. but here’s what Apple *actually* showed in WWDC 2019 (Data Flow Through SwiftUI): action → state → view (unidirectional data flow) they explicitly said “you no longer need view controllers” and the entire session demonstrated: - models as sources of truth - views observing models directly via property wrappers - no ViewModel intermediary layer call it what you want: M-V, MVC without the C, unidirectional data flow. the pattern is clear: models hold state/logic, views render and observe, data flows one direction. StoreKit 2, MusicKit, Apple’s sample code (Fruta, Food Truck) all follow this. models aren't anemic DTOs, they have methods, factory patterns, business logic my point stands: SwiftUI's reactive bindings eliminate the need for MVVM's 1:1 View-ViewModel translation layer. whether you call the alternative “M-V” or “MVC without controllers” is semantics

There is no "native MV" pattern. What people usually cite as evidence is the 40-year-old MVC diagram Apple used to introduce SwiftUI. I wrote about it here: #mvc-mvvm-design-patterns-swiftui" target="_blank" rel="nofollow noopener">matteomanferdini.com/swiftui-viewmo…

MVVM can fix the problem of massive SwiftUI views My recommended approach to MVVM in SwiftUI divides the view layer into two distinct categories: root views and content views. This division promotes decoupling and cohesion within content views, making your app's UI more manageable, testable, and reusable. Read how it works here: matteomanferdini.com/swiftui-massiv…

Are VIPER and MVVM radically different patterns❓ Many developers think so.🤔 However, architectural design patterns use the same core components.💡 In this article, I show how MVVM and VIPER in SwiftUI follow the same principles, even though they are implemented under different names.👇 matteomanferdini.com/mvvm-vs-viper/…

If you are just starting to make SwiftUI apps, most of your questions probably revolve around how to structure your code. You might already know some of the features of SwiftUI and the iOS SDK, but you can't bring them all together in a well-structured app. But even if you already have some experience, I believe you can gain much value from this guide. matteomanferdini.com/swiftui-app-ar…

SwiftUI's NavigationStack allows the building of sophisticated navigation hierarchies, using two types of NavigationLink: 🔵 Value-destination, pushing values onto a navigation path. 🔵 View-destination, pushing views onto the navigation stack. Their common use is perfectly acceptable in simple apps. However, it causes architectural issues at scale. Read about those issues here: matteomanferdini.com/mvvm-coordinat…

Monolithic SwiftUI views are hard to maintain, difficult to preview, and impossible to unit test. That happens because they get filled with tightly coupled code related to low cohesion tied to the app’s business logic: 🔵 Networking code 🔵 Error handling 🔵 State transitions These problems are solved by architectural patterns that distribute responsibilities across well-defined layers. Read more here: matteomanferdini.com/swiftui-viewmo…

Read the article here: matteomanferdini.com/mvvm-vs-viper/…

Are architectural patterns really that different from each other? In my new article, I argue that they are not, the same way buildings rest on common principles. I take apart the VIPER pattern and show the parallels that emerge with MVVM when you consider the role of each layer rather than its name. Link in the replies.

@corneliusmark Monolithic types will never die, every framework has its own version.

@MatManferdini Yep, UIKit's Massive View Controller architecture is still not dead.

SwiftUI developers often create massive views that accumulate a plethora of code. That’s simple at first, but it quickly leads to view code that is: 🔵 Untestable 🔵 Impossible to preview in Xcode 🔵 Hard to understand and maintain Read how you can take that code out of views here: matteomanferdini.com/swiftui-massiv…

Cramming data into a SwiftUI view’s stored properties can create structural problems. The standard approach is to pass data through a view’s memberwise initializer. Then, in the view’s body, use stacks and layout view modifiers. While straightforward at first, it can lead to layout issues that require additional code. Learn a better approach here: matteomanferdini.com/swiftui-views/…

SwiftUI provides several tools for managing navigation programmatically. However, in larger applications, vanilla SwiftUI navigation can pose challenges for testability, maintainability, and modularity. Navigation logic is distributed across views, introducing coupling and making the navigation code hard to locate. These problems can be addressed by integrating coordinators into the MVVM pattern. Read how here: matteomanferdini.com/mvvm-coordinat…

@SwiftDev_UI @friederix_ 🙄

@friederix_ @MatManferdini Yes @MatManferdini s first version was exactly what I did minus the insets so to you it might’ve not appeared as what you were looking for.

Complex SwiftUI views can turn your code into a tangled mess of nested stacks, layout view modifiers, and conditionals. By leveraging SwiftUI's complete toolkit, which includes built-in specialized views, view styles, and view builders, you can build configurable views with idiomatic code that's easier to customize. Read the full article here: matteomanferdini.com/swiftui-views/…

@friederix_ @SwiftDev_UI Dude, my first version has a list with two sections exactly like the one you say solved your problem.

@MatManferdini @SwiftDev_UI Different result, I tried yours 😊 look at my screen recording. Your original solution didn’t allow for the image to scroll alongside the List, it was fixed in place