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