Post not yet marked as solved
How many years we have to wait to config (without using UIKit) NavigationBar / TabBar standard, scrollEdge and compact appearance?
Post not yet marked as solved
How many years we have to wait to:
Change TextField placeholder color?
Custom TextFieldStyle (and include isFocused: Bool)?
Post not yet marked as solved
How many years we have to wait to change TextEditor background?
Post not yet marked as solved
The model is composed by Data Objects (structs), Service Objects (providers, shared classes) and State Objects (observable objects, “life cycle” / “data projection” classes). We should use the state objects for specific (or related) data and functionality, not for screen / view, as they should be independent from specific UI structure / needs, When needed we can share then in view hierarchy.
Remember (using state objects in views):
StateObject - strong reference, single source of truth
EnvironmentObject / ObservedObject - weak reference
Also (when async calls needed):
Define state objects (or base class) as MainActor to avoid warnings and concurrency problems
Define state object tasks as async, e.g “func load() async”, because for some situations you need to do other jobs after data load completed and async is more simple / sequencial than checking the “phase” (.loaded) using onChange(of:)
Big apps can have more models. This is just an example:
Post not yet marked as solved
WWDC 2022 - Data Essentials in SwiftUI
Post not yet marked as solved
I've seen a lot of questions about MVVM (in general and about testability) unnecessary limitations & problems in WWDC22 SwiftUI digital lounge.
I think developers should start understand & think SwiftUI, instead another platform's strategy.
Apple patterns has been used very successfully by Cocoa developers for decades. It just works, and you don't have to fight it. Jumping into more complicated patterns is not a good approach for developers. Your self, your team, your company and your users will thank you!
Post not yet marked as solved
Remember:
Avoid sacrificing software design for testability
Automated tests didn’t ensure a quality product
Last years I see a correlation between the increased reliance on automated testing and the decline in quality of software.
A real project that failed and I fixed, one of many problematic projects!
Companies must be careful with devs obsessed with SOLID principles and testability.
In 20 years of software engineering I've never seen soo bad & inefficient developers than in last years. In case of iOS there are very bad developers that come from Web or Android. They fight the system with other platforms concepts and testability talk.
Post not yet marked as solved
This is software engineering! KISS (Keep It Simple)
This is SOLID (complicated and obsessed people call this clean…. are you kidding?!)
Post not yet marked as solved
Sorry, the examples are not testable? Not clean?
Today developers are obsessed with tests and other ugly thinks. I see projects delayed with lots problems because devs today want to be SOLID and testable.
Agile, SOLID and over testing works like a cancer for development teams.
Sorry but if people want to be complicated they should move to Android or other platforms.
Post not yet marked as solved
Another suggestion.
Example from docs:
NavigationStack {
List(parks) { park in
NavigationLink(park.name, value: park)
}
.navigationDestination(for: Park.self) { park in
ParkDetails(park: park)
}
}
In this case, we are duplicating the “park” data because that park is already in the stack. The navigation stack contains the park and we are making an unnecessary copy for ParkDetails view.
Why not to use the @Environment to get the pushed value (in this case the park) on ParkDetail? Every pushed View most have the corresponding value available in the @Environment.
Before:
struct ParkDetail: View {
let park: Park
}
After:
struct ParkDetail: View {
@Environment(\.pushedData) var park: Park
}
Also we can do the same for other cases like modals:
struct ParkPreview: View {
@Environment(\.presentedData) var park: Park
}
Post not yet marked as solved
State and Data Flow
Manage Model Data in Your App
WWDC09-204
WWDC09-226
WWDC20-10040
WWDC21-10022
WWDC22-10054
Post not yet marked as solved
MVVM vs SwiftUI
Mail app
App Store app
Shopping app
Post not yet marked as solved
Another suggestion.
In many cases we don’t use the NavigationLink because we have a custom UI and can’t change de pressed style. Will be great to have a “NavigationLinkStyle” (with isPressed) or a NavigationButton or data-drive push capabilities for the Button.
In fact Button is used for push all the time.
Post not yet marked as solved
SwiftUI is a modern UI framework and in the declarative world MVVM (original) feels unnecessary and very limited. The problem is people understand what MVVM architecture is in fact. Maybe they are just calling every non-view objects (e.g. store, state, current, …) ViewModels but this is not MVVM.
Post not yet marked as solved
I understand your concerns but in case of SwiftUI (declarative) the “MVVM” (original from 2005) is not the correct approach. Maybe the problem is people calling ViewModel and MVVM.
Let me explain, in MVVM almost every View most have a ViewModel, basically you have a middle layer (data binding). In SwiftUI (declarative) you don’t need that, in SwiftUI you can use the concept of “Store” to do the odd jobs. In fact this is a “model type” but we should avoid call ViewModel (and MVVM) because the conflict.
This is MVVM:
HomeView - HomeViewModel
ProductListView - ProductListViewModel
ProductDetailView - ProductDetailViewModel
ProfileView - ProfileViewModel
This is SwiftUI:
CurrentProfile (or in generic Current<Profile>)
ProductStore (or in generic Store<Product>)
AppState / NavigationState
HomeView
ProductListView
ProductDetailView
ProfileView
Focus on the model (data + business logic)
Create views that reflect the model
If needed use a model type (e.g. Store) in your view layer to do odd jobs
But why I’m complain about the use of MVVM for SwiftUI? Because I worked for Microsoft platforms (community leader) and evangelist the MVVM from 2005.
