> Unless your objc code is written using nothing but id and reflection

That's how all Objective-C code is written–every method call goes through objc_msgSend.

To be fair to objc_msgSend it's orders of magnitude faster than most reflection APIs. https://www.mikeash.com/pyblog/performance-comparisons-of-co... has some benchmarks, it's a bit old but I don't think objc_msgSend would get slower.

Yup, I'm not saying objc_msgSend is slow: it's just that it's not faster than a direct call, and I believe about on-par with a virtual function call.

And let's not forget that ObjC is downwards compatible with C. If you need a particular loop or function to be fast, you can write it in C, in the same ObjC source file.

For one, ObjC can't treat objects as values or initialize them on the stack. Also, the everything-is-an-object paradigm is terrible for arrays of values, since every NSNumber or NSValue has to be individually malloced and released. (Though maybe not the case anymore? It was certainly a chokepoint several years ago.)

Both of these factors have forced me into using lower-level Objective-C++ code on numerous occasions.

NSNumbers are generally tagged pointers, unless you’ve got a really large number.

This didn't help me in my app, unfortunately, because I needed to encode CGPoints as NSValues. I suppose I could have resorted to ordinary, interleaved CGFloats, but it was way easier and more productive to just use C++ vectors. I knew exactly what I was getting with those, and I didn't have to do the boxing/unboxing dance.