This is a cultural issue much more than a technical issue.  I can relate to both sides.  &quot;I want to be able to patch anything myself,&quot; versus &quot;I want to be able to reliably reason about how my module works.&quot;<p>The rhetoric on both sides can quickly get stupid.  This is one of the major ways in which languages are divided.  Ruby folks are used to being able to monkey patch everything, and Python folks tend to avoid it even though they can.  JavaScript programmers are divided on the issue: should you add a method to Array.prototype, or is that just asking for trouble?  I&#x27;ve certainly seen my own fair share of bugs and crashes caused by programmers substituting types where they shouldn&#x27;t, and seen my fair share of frustrating limitations in sealed modules that should just expose that one method I need, dammit.<p>Objective-C leaned towards the &quot;go wild, do anything&quot; approach, which grew quite naturally out of the minimalistic &quot;opaque pointer + method table&quot; foundations for object instances.  One of the reasons that you make such a choice in the first place is the ease of implementation, but in 2015, writing your own compiler is easier than ever.  So Apple is quite naturally considering application reliability as a priority (since they&#x27;re competing with a platform that uses a safer language for most development).<p>Unfortunately, it&#x27;s a cultural fight where one side or the other must necessarily lose.