It has lead to a very modular and maintainable app that has been very easy to test without ridiculous mocking you usually see when needing to interact with object-oriented / imperative frameworks like Cocoa Touch.
With this approach: 1. What downsides have you encountered? 2. How easy do you find it to onboard people? 3. Does Android do the same at your place?
Our next big effort will be fitting the architecture into SwiftUI, which I think will actually be also straightforward since SwiftUI is extremely functional.
2. Onboarding is probably the biggest “downside”. I would say there is absolutely a learning curve that requires some investment but everyone I speak to about it has been pretty positive after getting over that hurdle. And it feels like our productivity is very high.
3. Android does not follow the same pattern. I am planning on sharing your article with the team though. :-)
1. Create a struct (value type in Swift) that implements a protocol (interface) to serve as your ViewModel 2. The main methods to implement are both called “update”. One is called automatically by our infrastructure when Feature state (state that exists across screens) changes. The other is called by the developer in their view controllers to pass along user actions (or other UIKit events). 3. The developer subscribed to all VM changes and updates the view in response. This subscription is done via Combine which is Apple’s FRP framework.
I am planning on writing more about this and the rest of our architecture in the future, hopefully.