u/Revolutionary_Fun69

Hello, in my previous post https://www.reddit.com/r/SwiftUI/comments/1tfn2jz/protocol_oriented_view_architecture_for_modern/ I discussed the Protocol Oriented Views for SwiftUI apps which has advantage of nil-safety, observing SwiftData queries and almost zero boilerplate.

I prepared an example (I'll add unit tests in part 3)

Please check it out
https://github.com/nusov/SwiftUI-POV-Architecture/tree/main/Breakthrough

In this example, I didn't create a separate protocol for models; it is highly simplified, but it conveys the main idea.

App State (Global Observable, for future use, inject once in the RootView access everywhere)
App Repository (Controls main data cycle seed/reset)
App Settings (Persistent settings, I used AppStorage but you can use any library or plain UserDefaults)
ModelContainer with factories for live app and #Previews
AppSchema
UI and some binding using POV architecture
Everything is Observable, thanks for comments in the previous post I fixed some flawsю

Feedback is highly appreciated

Hello! I'm working on a personal pet project in SwiftUI and trying to utilize all of its newest features. Along the way, I realized that traditional MVVM often feels like it's fighting against SwiftUI. TCA feels too heavy and complicated for small-to-medium projects. Unlike Google, Apple doesn't really provide definitive, official architecture recommendations.

Because of this, I designed a testable, protocol-based architecture focused on high separation of concerns and reusability.

Core points:

Logic Injection via Extensions: Business logic is not inside the View or a ViewModel, but in a Protocol extension. This is "Composition over Inheritance."
Direct Environment Access: The View accesses dependencies (SettingsManager, RoleService) directly via \@Environment, eliminating the need for manual dependency injection pass-through.
Separation of State and Behavior: The u/Observable class holds what the data is (State), while the Protocol defines what happens to it (Behavior).
Self-Initialization: The View is responsible for fetching its own dependencies and initializing its own state, removing the need for parent "Factory" views.
Reduced Boilerplate: Eliminates the need for a separate ViewModel class file and the verbose binding syntax often associated with MVVM.

In this pattern:

The Protocol defines the contract: the required dependencies (services, modelContext) and the functions (business logic).
The Protocol Extension provides the default implementation of the logic. This allows the code to be written once and reused by any view conforming to the protocol.
The View conforms to the protocol. It holds the UI layout, declares its dependencies using u/Environment, and manages a separate u/Observable State class to hold data.
The State is a pure data class (ViewState) that handles the mutable properties, ensuring the View struct remains lightweight while keeping data persistence correct.

Check it out here: https://github.com/nusov/SwiftUI-POV-Architecture/tree/main

Your business logic stays on the same View level, no more optionals, initializer chains.

Protocol Oriented View Architecture for Modern SwiftUI applications (Part 2)

Protocol Oriented View Architecture for Modern SwiftUI applications.