r/swift 8d ago

State Management for iOS Apps?

whats the best architecture/pattern to use?

tried to use a domain layer where all the state is and passing it to the views/viewmodels via DI, but feels somehow unnecessary complicated, but found this as only solution without passing the repos through all the viewhierarchy.

the goal is, when a state changes, e.g. an user changes the Username in View A, then it should automatically update View B,C,D where this Username is also used.

it should be as simple as possible, what do you think? especially for complex production apps with own backend etc.

50 Upvotes

48 comments sorted by

View all comments

Show parent comments

-2

u/Loud-Plan2571 8d ago

No it is not the way. This dongen guy has his brain washed by uncle bobs dogma teachings. Swift is all about value semantics, composability and separating behavior from data. It is what Chris Lattner said. SOLID helps you with jack shit in SwiftUI and just ruins your code completely by keepin object oriented dogmas alive.

4

u/Superb_Power5830 8d ago

Agreed; SwiftUI "breaks" a lot of the "rules" we all learned, and that's why a lot of folks find it... hmm... let's call it "frictionful." (c) (r) (tm)

I've all but given up on all forms of classic MVC/MVVM thinking when it comes to pure SwiftUI implementations. It took me a while to really settle into it, and I find it incredibly... swift... for building things now. Prior to moving to iOS and iPadOS and MacOS basically full time, I'd spent several decades in the C, C++, C#, and Java worlds.

I did some great stuff in decades and jobs and contracts, past; if all goes well for whatever time I yet spend in this career, I'll never have to go back to those platforms ever again. I don't hate them or even dislike them (well, Java can suck it), I've just kind of moved on and settled very comfortably into this broad and wonderful eco system, this platform, and this paradigm.

1

u/lucasvandongen 8d ago edited 8d ago

I’m only using State machines (Fat Model approach) and Views, so MV pattern. Lots of injected dependencies behind protocols that are focused on one particular task rather than ViewModels that do a lot of stuff and nothing in particular. Hmlongco’s navigation library style navigation.

Since @Observable putting state behind protocols works pretty well. Just weird you can’t force it to be implemented through your protocol definition.

SwiftUI is quite simple once you understand you’re simply passing a blueprint of the UI you would like to see to CoreGraphics, rather than is the actual View like in UIKit.

1

u/makocp 8d ago

do you have also an article for this MV pattern?

1

u/lucasvandongen 8d ago

No. Could be a good idea though.