(Oops, I meant table view, not scroll view. Thanks.)<p>I agree with you on the specifics, but somehow still reach different conclusions. :)<p>Edit: I guess if you take the lense of wanting  Swift to replace the combination of ObjC + plain C, what you&#x27;re saying makes sense.<p>It&#x27;s a shame though if you end up losing the very-helpful ability to dynamically modify system provided behavior.<p>And even for relatively performance intensive stuff, like table scrolling, objc is plenty fast.<p>Every language obviously has its domain of performance-appropriateness -- C too will hit its limits; x264 w&#x2F;o the asm optimizations is ungodly slow, for example.<p>I just think for &quot;apps&quot;, generally, objc is a speedy language. Empirically this is true. Explanations that call for this being true &quot;despite the language&quot; are suspicious to me; if it&#x27;s not the language, what&#x27;s the magic pixie dust?<p>And personally I suspect the swift folks aren&#x27;t going the more static route because of actual real-world user-facing performance walls they&#x27;ve run into, but because that&#x27;s what they&#x27;re into -- they&#x27;re C++&#x2F;static language&#x2F;compiler guys.<p>Last example: Look at the most performance constrained stuff apple is currently doing, the watch. Think that&#x27;s Swift? I&#x27;m pretty sure it&#x27;s not.