I'd argue that "massive view controllers" aren't "normal", and if you find yourself in situations with massive view controllers, those are likely excellent candidates to refactor into smaller view controllers that can be composed together using something like iOS view controller containment. Well-disciplined iOS developers can keep this under control.

I'll turn the question around - don't you see the potential for the same kinds of poor development practices that lead to "massive view controllers" to be just as prevalent with an approach like Katana? So far, I see nothing in Katana that will prevent poor developer discipline.

So - (and I say this mostly in jest) - if you have poorly disciplined developers, now, with Katana, you have two problems: 1) the same kinds of code quality issue that you'd have without Katana, with 2) the added downside of no one understanding yet another overly complex application framework.

You have a lot of comments on this article, with some good questions and good points. However, I think there's a theme in some of them:

> Well-disciplined iOS developers can keep this under control.

Well-disciplined iOS developers with good development practices were also able to manage manual reference counting. However, I think it's widely agreed that ARC was a step forward for iOS development. Similarly, the Swift language has eliminated whole classes of bugs - ones that expert developers didn't often struggle with but nevertheless were problematic for the platform as a whole.

Personally, I love developing for iOS. I don't think there's anything broken with Apple's frameworks. I tend to be conservative and would prefer to rely on first-party provided frameworks & libraries when writing an application, with judicious use of 2nd & 3rd party code.

However, I believe there will be a better way to write iOS apps in the future. I think there's a lot of accidental complexity involved that must be simplified eventually. I don't think Katana is the solution. But I'm very curious to find out if it's a step in the right direction.

Comparing referencing counting and following a disciplined convention in coding are not the same thing. ARC was a step forward because it eliminated a nuisance inconvenience from your development which most of the time was not related to the problem you were solving.

Following a good and disciplined programing convention is more of an overarching theme of how you solve your problems. It practically defines your style and no amount of forced framework convention will be a step forward unless you're willing to take it.

That is one of the most common complaints about iOS.

Unidirectional data flow greatly reduce complexity because you don't to reason about several places making changes of the state.

I'm programming Elm after 3 years of iOS and, man, it's great. The amount of code I'm reasoning about is always contained in a in single vim window. It's something that can be done in iOS, but it would require very high discipline. In Elm it came naturally.

This seems like a reinvention of MVC -- your view is supposed to render your model (the state) and the controller is supposed to act on the model (actions).

The web complicates MVC but in standard desktop/mobile apps MVC is pretty straight forward.