&gt;iOS&#x27; performance is great in spite of using Objective-C as its language, not because of it.<p>Nope.  Objective-C is a <i>great</i> language for performance.  Remember the 97-3 rule.  That is, only roughly 3% of your code are responsible for almost all the performance.  You just don&#x27;t know which parts those are.<p>The dynamic features of the language give you awesome productivity to more quickly get to the point where you find out which 3% to actually optimize heavily. Doing this optimization is straightforward because you have all the tools at your disposal, the road to them is smooth and the performance model is predictable.<p>I have repeatedly achieved performance that&#x27;s better (yes!) than equivalent C programs, and with a little bit of work you can actually maintain nice OO APIs.<p>&gt;(b) being compatible with C so you can easily inline C into Objective-C<p>I really don&#x27;t understand where this (common) misunderstanding is coming from.  Objective-C <i>is</i> C, or more precisely a superset of C.  You don&#x27;t &quot;inline C into Objective-C&quot;.  You use different aspects of Objective-C as appropriate.  If you are not capable of using the full capabilities of the languages, that is your fault, not a problem of Objective-C.<p>This seems to have been lost, with people (inappropriately) using Objective-C as a pure object-oriented language.  It is not.  It is a <i>hybrid</i> object-oriented language.  In fact, the way it was intended to be used is to write your components using C and use dynamic messaging as flexible packaging or glue.<p>&gt; because methods can&#x27;t be devirtualized<p>Sure they can.  I do it all the time:<p><pre><code>   SEL msgSel=@selector(someMessage:);
   IMP devirtualized = [object methodForSelector: msgSel];
   for (i=0;i&lt;LARGE_NUMBER;i++) {
       devirtualized( object, msgSel, arg[i] );
   }
</code></pre>
Did you mean they can&#x27;t be automatically devirtualized by the compiler?  I hope you understand that these are two different things.  Of course, it would be nice to have compiler support for this sort of thing, which would have been miles easier than coming up with a whole new language:<p><pre><code>   for (i=0;i&lt;LARGE_NUMBER;i++) {
       [[object cached:&amp;cache] someMessage:arg[i]];
   }

</code></pre>
Or some other mechanism using const.<p>&gt; reached the limit of what they can do without incompatible changes to the Objective-C semantics.
&gt; Hence the performance-related design decisions in Swift.<p>Swift performance is significantly worse and waaaayy less predictable than Objective-C, and that is despite the Swift compiler running a bunch of mandatory optimizations even at -O0.