|
|
|
|
|
by king_magic
3500 days ago
|
|
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 :) |
|
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 :)