[lucaquerella]

It may be an overkill for super simple apps with just few views. But it works great with a larger codebase, at least for us. We have apps built with it with hundreds of views and it works great, it has halved our development time and helped us to have a more structured and clean approach to the state management.

[king_magic]

How do you know it halved your development time? Do you have metrics from projects executed using standard iOS conventions vs. projects using the Katana approach? Or, asked another way, what - specifically - about this approach halved your development time?

In my experience, state management hasn't really been a bottleneck in iOS development, at least not to the point where it could account for half the effort of a project (or even 25%), and I've worked on some monster iOS apps.

Forgive me for being skeptical here, but I think this is one of those extraordinary claims requires extraordinary evidence situations. "It works great" sounds great and all, but I'd have a hard time convincing a dev team to adopt an approach because someone says it works great :)

[lucaquerella]

I don't blame you for being skeptical.

The main advantages we've noticed using this pattern are:

1) every time there is a crash or a problem we can look at the the state and the actions that lead to that situation. This improved our ability to spot and fix bugs.

2) we can easly reproduce any appearance of the UI by providing a struct the rappresents the state of the app. This has improved our ability to QA the entire UI quickly.

3) with this architeture we've been able to refactor the code in simpler unit of logic rather then creating big VC. This has improved the readibility of our codebase.

4) it's easier to reason about the UI with the Katana (that is, declarative) approach rather than having to handle mutations

I'm not saying this is a solution for every problem but I can tell you that we internally used it and liked a lot so we felt like sharing our work with the world :)

[ianterrellwt]

Hi lucaquerella. I've been working on a similar bit (minus the React-inspired UI) here (combining ReSwift with app coordinators): https://github.com/willowtreeapps/cordux

We've also found reproducing the UI via state to be a huge win. We're using FBSnapshotTestCase to generate snapshots of our app across different controllers with different states, automated to take snapshots on different devices and in different orientations.

Glad to see other people are pursuing these ideas!

[king_magic]

Those are legitimately interesting advantages - thank you for replying. Those would make really interesting deep dives blog posts / videos for making a case for Katana.

[bolismauro]

We haven't (yet) blog posts about Katana advantages, but if you want to try it yourself here you can find a very simple tutorial that will guide you in creating a very simple game

https://github.com/BendingSpoons/katana-tutorial-swift

It explores the core concepts of the framework and gives you an hint about how it feels to develop applications with this approach