Matteo | Swift, iOS, Best Practices

Monolithic views are the most common issue in SwiftUI codebases, especially among inexperienced developers. While the declarative nature of SwiftUI makes it possible to quickly put together complex user interfaces, it also makes it easy to create massive view bodies that soon become unmaintainable. In this new article, I show 3 strategies to modularize your code and make SwiftUI views more reusable. matteomanferdini.com/swiftui-reusab…

You can create custom styles to change the appearance of many built-in SwiftUI views. Styles are passed through the environment, so you apply them at any level of the view hierarchy, affecting even views you can’t access directly. Moreover, you can apply styles conditionally based on external factors, such as containers and platforms, without changing a view's structural identity. Read more here: matteomanferdini.com/swiftui-views/…

Root views are purely glue types that bridge between the user interface and the lower layers of an app’s architecture. However, moving user interface code into content views immediately simplifies the code of root views. Read about this little-known distinction here: matteomanferdini.com/mvvm-root-view…

Why are architecture and design patterns fundamental to any software project? Software architecture is important because it enables you to: 🔵 Decide when and how to apply design principles. 🔵 Improve the maintainability of your codebase. 🔵 Discuss issues with other developers. Learn how in my new mini-course: iosfoundations.com/swiftui-archit…

SwiftUI Weekly Newsletter - Issue #233 is here! This issue highlights the content by @natpanferova @MatManferdini @gabtheodor @ns_vasilev and other folks, which I can't find on X. weekly.swiftwithmajid.com/p/swiftui-week…

@ianmedeiros_ I haven't looked into it since I didn't need it yet, but I think Swift Async Algorithms is what you are looking for: swift.org/blog/swift-asy…

@MatManferdini It seems to me that the missing pieces for async/await api on swift are functional operators. We need things like await .combine{} or .map{}. This seems like the missing building block to replace the existing .combine for structured concurrency.

AsyncStream is a Foundation type that lets you easily create asynchronous sequences for use with Swift Concurrency. Moreover, according to Apple documentation: ❝ In particular, an asynchronous stream is well-suited to adapt callback- or delegation-based APIs to participate with async-await. Read how to transform delegation into a stream here: matteomanferdini.com/swift-asyncstr…

@InvShahid I'm currently doing some research on agents and skills. I hope to have something to publish soon

@MatManferdini Have built skill exactly for this for agents like codex

SwiftUI views do not behave like regular Swift structures. They only represent what should appear on the screen, which the framework uses to render your app’s user interface. The app’s data must be stored in a single source of truth, as illustrated in Apple’s introductory SwiftUI talk from WWDC 2019. Learn how that works here: matteomanferdini.com/swiftui-data-f…

@ianmedeiros_ Yeah, especially in large projects, even renaming a type sometimes messes things up or straight up refuses. We can only rant, or work with another IDE 🤷🏻

@MatManferdini Yeah, Xcode refactor tools are a disaster. It’s cool to point them out, but they absolutely suck. Takes forever end fail extremely often. Nice article thought. That’s just my daily dose of XCode ranting, without it we blow up full of anger.

Monolithic views are the most common issue in SwiftUI codebases, especially among inexperienced developers. While the declarative nature of SwiftUI makes it possible to quickly put together complex user interfaces, it also makes it easy to create massive view bodies that soon become unmaintainable. In this new article, I show 3 strategies to modularize your code and make SwiftUI views more reusable. matteomanferdini.com/swiftui-reusab…

If you are into iOS development or have recently started building apps, I would recommend following the people below 👇 based on my recent experience and their work history. > @PaulSolt - Don’t forget to subscribe to his “AI Code Brief” newsletter. > @seraleev - Just checkout his recent growth on X to know why I am suggesting him to follow. > @twostraws - Paul Hudson of Hacking with Swift; his free tutorials, projects, and books are gold for anyone just starting to ship apps. > @DonnyWals - iOS engineer + author who breaks down real-world Swift topics (Combine, async/await, etc.) in his blog-super actionable. ——————— Below accounts are suggested by Grok. > @mecid - Majid Jabrayilov, SwiftUI addict who drops weekly deep-dive posts and curates SwiftUI Weekly newsletter. > @natpanferova - ex-Apple SwiftUI engineer turned author; her books and insights give you insider-level knowledge without the fluff. > @MatManferdini - Matteo shares clear app architecture best practices and free guides-perfect if your code is getting messy fast. > @MengTo - founder of designcode. io; teaches SwiftUI + design/animations so your apps don’t look generic (great AI-to-code workflow tips too). > @krispuckett - Stripe designer & indie builder; drops Apple’s own performance tips tailored for SwiftUI + AI-powered apps. > @onmyway133 - Khoa, successful indie dev behind App Store hits; practical SwiftUI tips from someone actually shipping apps. > @VinnieiOS - iOS engineer who explains data flow, state management, and SwiftUI fundamentals in clear threads for all levels. > @ThoseWhoSwift - official account for the ThoseWhoSwift newsletter; consistently surfaces the best new SwiftUI articles and document-based app workflows. Feel free to add more 🙌

@mecid @natpanferova @gabtheodor @ns_vasilev Thanks for the mention!

The sleight of hand that removes the C from MVC and thus makes the MV pattern look new is the renaming of controllers into aggregate models. This way, we can pretend they are part of the model layer, and that MV is totally not MVC. Read why they are the same here: matteomanferdini.com/switfui-mv-pat…

The first information you need when interacting with a REST API is a list of its endpoints. These uniform resource locators (URLs) provide the locations of all the API resources on a server. 🔵 REST APIs typically have a base URL from which all other endpoints are derived by adding a path. 🟠 The desired response can be further configured with query string parameters or, in some cases, additional HTTP headers. Often, you have to assemble each endpoint URL from its components. However, some APIs return most endpoints in their responses. Learn how to perform REST API calls in Swift here: matteomanferdini.com/swift-rest-api…

Developers often think MVVM and VIPER are radically different because of the diagrams commonly found online. VIPER is an iOS implementation of the Clean Architecture by Robert C. Martin, the same author of the SOLID principles. However, in my research, I have not found an explicit explanation of how VIPER adheres to those architectural principles. Read more here: matteomanferdini.com/mvvm-vs-viper/…

My favorite easy-to-understand metaphor for SwiftUI Architecture is building a house. While there are different approaches, all houses share the same structure: foundations, walls, doors, windows, and a roof. Whether a house was built yesterday or 2.000 years ago, its blueprint remains the same because it’s the only one that makes sense. If you deviate, the house will fall apart or nobody will want to live in it. SwiftUI apps work similarly. Learn more with my free guide: matteomanferdini.com/swiftui-app-ar…

@_MarlonJames That can work for shared objects that contained functionality used by several views. However, some views require specific code that should not be visible to other parts of the app. Using the environment is not a solution in those cases.

@MatManferdini What about using the environment?

Injecting view models into a SwiftUI view from its parent view creates coupling between views. It also violates the Single Responsibility and Don't Repeat Yourself (DRY) principles, especially when the view is accessible via multiple navigation paths. We can avoid these problems by injecting the dependencies into the view model from a coordinator. Read more here: matteomanferdini.com/mvvm-coordinat…

@malhal A binding requires dependency injection, which violates the principles I mentioned.

@MatManferdini Or you could use @.Binding which is built in.