The problem is that the core design of NSCodable (and NSSEcureCoding) is that the serialized data get to specify the type to instantiate, and the way supportsSecureCoding is exposed means that the claim to secure coding is inherited.
The former is a fairly common problem in serialization systems, and the security flaws in that approach resulted in the subsequent NSSecureCoding APIs.
The latter is a byproduct of how secure coding is implemented, and it results in any user of NSSecureCoding needing to be aware of all classes that may be transitively pulled into their address space. The subclassing semantics means that even the explicit list of allowed classes is not sufficiently robust - e.g '@interface ArbitraryInsecureClass : NSData' means ArbitraryInsecureClass can be instantiated if you allow NSData in the secure coding list, and ArbitraryInsecureClass could be declared in some transitively included framework, and is generally leaked implementation details.
These are all "fixable" for some value of fixable constrained by binary compatibility (though some of it could be mitigated by Darwin's linked-on-or-after mechanisms). There are a variety of steps that Apple could take that would make the entire NSCoding mechanism much more safe/secure without (afaict) necessarily breaking anything, though obviously I don't have access to the compatibility information they probably have.
Things I would do (if I were king?):
* Compiler warning when you subclass a class that declared supportsSecureCoding
* Make the allowed classes restrict to explicit classes rather than just conforming classes (e.g. if you say NSData you can't instantiate a subclass of NSData) - I would give good odds of this breaking things
* Rather than just checking the value of TargetClass.supportsSecureCoding I'd query the runtime to require supportsSecureCoding being a direct class member of TargetClass
* I would consider adding a "+property secureClass: Class" (or whatever the syntax is) that is instantiated, so even if you aren't using secure coding you end up instantiating a sane type - though it would be "optional" due to existing code and objects not having the property. But then at least Apple could go through the core types in Foundation (Array, Data, String, etc) and make it so you would only ever instantiate understood classes.
This would make the API slightly less footgun heavy.
