> And yet, Apple still use NSCopyObject themselves to this very day Of course they do. The existing behavior involves NSCopyObject (for decades at this point)

> And yet, Apple still use NSCopyObject themselves to this very day Of course they do. The existing behavior involves NSCopyObject (for decades at this point) and user code written against those existing APIs, therefore depends on that behavior. Even if removing the NSCopyObject usage would make things "better" in principle, doing so would likely break existing code so it simply isn't an option. Hence it's deprecated, and all the documentation says "don't use this", but the system still does, not because Apple is being hypocritical, but because it has to support existing code. That's just the reality of providing ABI stability on any OS: sometimes you have to do distasteful things - an example I'm acutely familiar with is with JSC's API on 32bit platforms: the internal representation of js values is 64bit, but the API is 32bit so sometimes accessing a property can result in GC allocation of an object to wrap immediate values.