The architecture is unidirectional, and all side effects are isolated into separate modules. The reducer is basically a pure function that transforms the state as a state machine.
Interesting bits:
- CoreMotion on iOS is notoriously tricky when you want to get the status of permissions. The status is not updated in runtime and depends on sequence of actions taken by the user. By modeling state as an algebraic data type (ADT) and describing all actions that can happen, we were able to model even the dead state when permissions can never be asked without restarting the app (MotionLive/MotionLive.swift)
- The application's state is modeled using algebraic data types in a way where invalid states are unrepresentable, so the user can't possibly get into them. State machines are hard to decompose and then compose together, but with contramap, it's possible (App/App.swift). So there are many child state machines with ADT state that compose into a big one.
- Views are also modeled as a separate ADT that knows nothing about reducers and often combine work from multiple ones. This way, reducers can focus on the state they care about (that is grouped by transitions), and views can focus on a state that needs to be shown (based on screens), and all of them can't be in an invalid state (ViewBlocker module as a good example).
- Lenses, Prisms, and Affines are used to extract the needed bits of state and then create pipeline transformations of it without recreating the whole state (which can require a lot of boilerplate if done imperatively). A good example is (SignIn/SignIn.swift), which juggles a lot of nested complex states in a small package.
And a lot more, ask away.