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.
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.