I can't speak for the author, but you could take it as an argument against inheritance in general. There are a lot of smart people in that boat -- I think at one point even James Gosling said he might have left inheritance out of java if he had it to do over again.
I probably have no shot of convincing you that inheritance kind of sucks in a short post on a friday night, but I'd just point out that it's not an obscure opinion, there are a sizable number of people that really have no love for the "classic" inheritance model of OOP.
No doubt, and I'm not really debating the language design tradeoffs involved in various approaches to OOP (or heck, typing in general). It's just this kind of talk comes up from time to time, seems to be fear-driven, and ignores the pragmatic practices that have been developed to work with inheritance (or any number of other language features that trigger a similar reaction, c.f. Pythonistas vs Rubyists on the topic of monkey-patching).
It was surprising enough in context of an otherwise incisive article that I was honestly wondering if there was something specific to Swift and/or the ObjC framework world that posed a unique hazard.
Speaker here. Nothing particular although ObjC lacks any language based features to control inheritance. The concern is that if a method has a particular effect on state (possibly even private internal state) that you expect to take place that subclasses may override the method in such a way that it changes all the expectations and may leave you in an inconsistent state. This means that it is necessary to document (or have conventions for) what should and should not be overridden and whether overriding methods should call the superclass implementation too.
In unsafe languages with raw pointers the issues may be more severe than languages like Python and Ruby but they are generally similar.
I may have overstated the point too, I had notes but not a script. The point is that you need to be careful designing and documenting for subclassing.
There's an in-between option seen in some languages where you don't inherit and override but instead implement a superclass's stub (or event if you want to think of it another way), which I think gives almost all the benefits of inheritance without most of the downsides. Sadly it hasn't penetrated the "major" languages.
That would negatively effect the encapsulation benefits of inheritance: we could never safely access private fields on any value other than "this." Try implementing binary methods without that!
Inheritance should evolve...there is plenty that can be done with it (e.g. mixin-style inheritance, dynamic inheritance, family inheritance). At the very least, we should have that conversation on how to address inheritance criticisms.
I probably have no shot of convincing you that inheritance kind of sucks in a short post on a friday night, but I'd just point out that it's not an obscure opinion, there are a sizable number of people that really have no love for the "classic" inheritance model of OOP.