(Oops, I meant table view, not scroll view. Thanks.) I agree with you on the specifics, but somehow still reach different conclusions. :) Edit: I guess if you

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