I've been using this for a couple of projects and I really like it so far.
It's a nice take on unidirectional data flow as it applies to the Swift type system.
It brings a lot of clarity to the design. If I want to know the state involved in a view it's all explicitly stated in one place. If I want to know where state is manipulated, that's in the reducer.
Would you say it's good enough/stable enough for production use yet? I've been keeping an eye on ReSwift for a while now, but i've been hesitant about using it for anything serious because there doesn't seem to be any real apps out in the wild using it yet (AFAIK). Would really like to model my app state with the Redux-like pattern, from a single source of truth.
It's in use in production. We are using it in our internal apps now. Some apps in Japan have been appearing in the App Store using it, such as: https://itunes.apple.com/jp/app/id1088140538.
I would recommend trying to build an app using a DIY store following the principles first to get a really good feel for how it fits in. Moving from DIY -> ReduxKit -> ReSwift has been really easy.
Yes, I would consider it production ready. The library itself is really small, which means you don't paint yourself in a corner by using it.
We're still early on, so there are many different implementation patterns that might evolve around the core library but in my experience and that of other devs I've talked to it is already a pretty good step forward from an MVC approach.
I love the approach. Been using it for my latest projects and the results are amazing: having a clearly defined app state at all times makes lots of view updates so much easier.
It's a nice take on unidirectional data flow as it applies to the Swift type system.
It brings a lot of clarity to the design. If I want to know the state involved in a view it's all explicitly stated in one place. If I want to know where state is manipulated, that's in the reducer.