[taway555]

I'm currently at a company where our iOS product has millions of paying customers. FWIW:

We run a flavor of the coordinator pattern + MVVM. We use delegation to handle messaging between view models and view controllers. Services are currently handled by a super ugly singleton, but that's a by-product of legacy architecture. New features usually inject the service directly into the view model.. and there has been some talk in potentially moving the service to the coordinator to mimic a unidirectional data flow.

The issues you mention, i.e. globals, lack of unit testing, fat view controllers and lengthy functions... none of that stuff, if included in a pull request, would pass our code review. So generally we self police each other to avoid code smell.

[gregkerzhner]

I think the thing that is very tempting to do is to just have a ViewModelDelegate (which would be the controller) that has one method `func stateChanged(state: ViewState)` and then have the controller rerender itself whenenver that function is called. This would be nice and redux-y since the view could be a pure function of the state. But since iOS doesn't have a declarative user interface or the virtual dom, you would potentially be rerendering the whole screen when just one part of it needs to change. How do you guys overcome that? Or do you have multiple delegate methods that the view model calls on the controller depending on what needs to happen?

[disposedtrolley]

I don’t have much experience in iOS/Swift, but would SwiftUI address the declarative part?

From what I’ve seen you can supply state to a view and it’ll take care of the rendering for you.