A few weeks ago I came across an article by Robert C. Martin titled the churn. The gist of the article is about developers turning to new Technologies, Languages and Design Patterns too quickly and throwing away their hard won experience overboard as a result of it.
The article reminded me of what I read about Swift in the first few months after its initial release. I remember problems with source code stability due to ever changing Swift versions, problems with XCode (Sourcekit crashes & App Store submission problems), long compilation times and the search for an answer to the question of what good Swift code actually looks like. The whole Swift community tried to come up with solutions. Was this what Uncle Bob's article was about? I mean why turn away from Objective-C so quickly? Why leave the comfort of a stable IDE and established design patterns behind and code without XCode's refactoring tools? Were we all fools blended by the promises of a better language? Looking at the evolution of Swift and our application of the language in the past few years you definitely can find something to agree with Uncle Bob.
It is true that we all had to struggle with Sourcekit crashes. Yes, indeed, but only when we were writing Swift code. We never had to leave Objective-C behind. On the contrary, Apple made it quite easy for us to work with both languages next to each other from the very beginning using the IDE we were already accustomed to (let AppCode be the exception here if that was the IDE of your choice). Neither did we have to leave old design patterns behind. MVC, MVVM, Delegation, Singletons,... are still used and applied in Swift. In addition to those, new patterns and paradigms became available. And by new I don't mean new as in fresh from the oven. Design patterns, Paradigms and ideas were added from well-established Languages like Haskel. Protocol Oriented Programming (POP), Functional Programming, Generics a.s.o. were used in other languages for decades. For example, as far as OOP is concerned, it is and will be an essential part of Swift. But that doesn't mean it's the only answer to flexible and stable code. For example, Polymorphism next to Encapsulation and Inheritance is one of the corner stones of OOP. It allows an object to declare its methods independent of the underlying object. But doesn't a protocol do exactly the same by saying to what a conforming data structure (Classs or Struct) needs to implement. Isn't that even an higher level of abstraction? Don't get me wrong. I am not saying, let's forget OOP, from now on it is POP only. I am saying both have their use cases. I don't even think Apple said this. I mean in the famous WWDC talk with Crusty about POP, Apple wanted to show us something new and the uses cases demoed were of course all in favor of POP.
Change is good. To make something better we need to change it. That's progress. So what? What's the verdict? Can the article be applied to Swift or not? The way I see it, the article is about radical change. Uncle Bob is not talking about no change at all and in the light of this, Apple, the Swift community and every App developer did good. We always had some solid footing. Sure the road was here and there a little rough and uneven but that's behind us. It's getting better day by day.