iMessage has a large base of existing users that need to be able to continue to use messages, and presumably it was thought that by restricting with the NSSecureCoding API it would be safe, but as you say any API where the remote specifies the class to instantiate is going to be something of a footgun.
iMessage also predates MessagePack, BSON, and many of the other now "common" and "obvious" serialization formats, so you're (kind of) saying "why didn't it use a format that didn't exist".
The reality of course is that in addition to everything else NSCoding is the language supported serialization system, and not using it would have been an example of "reinventing the wheel". The reality is that the engineers using NSCoding + NSSecureCoding quite reasonably expected it to actually be secure (it's right in the title).
All those things aside it irks me that any of the message processing happens in the springboard process rather than a separate sandboxed process that doesn't have essentially complete access to everything that exists.
iMessage also predates MessagePack, BSON, and many of the other now "common" and "obvious" serialization formats, so you're (kind of) saying "why didn't it use a format that didn't exist".
The reality of course is that in addition to everything else NSCoding is the language supported serialization system, and not using it would have been an example of "reinventing the wheel". The reality is that the engineers using NSCoding + NSSecureCoding quite reasonably expected it to actually be secure (it's right in the title).
All those things aside it irks me that any of the message processing happens in the springboard process rather than a separate sandboxed process that doesn't have essentially complete access to everything that exists.