Wallclock time isn't the only performance metric to care about. ObjC had a GC in the past and lost it in favor of ARC for a reason; it's a poor fit for iPhone-sized devices.

That was the marketing reason, the official reason was that fitting a GC into a language with C memory model wasn't never going to work, and there were plenty of crashes and memory corruptions coming out of that.

So they made the only sensible decision, and just like Microsoft did with COM, they added support to the Objective-C compiler to automate retain/release messages in OS X Frameworks.

Naturally being Apple, that pivot had to be sold in a way that the reason was being of RC being better and not because of the technical failure to have a tracing GC in Objective-C , while remaining compatible with C memory model.

Apparently, moving the GC document with all its caveats regarding possible programming issues, out of search index also helps to keep the story as well.

https://developer.apple.com/library/archive/documentation/Co...

No, the performance issues are real. GC programs have more page demand and higher peak memory use, which is specifically what the iOS memory model (jetsam and memory compression) can't deal with well. They can have some wins due to compacting.

There is of course a GC language on iOS (JavaScript) but expensive webpages get killed quickly.

And yet Microsoft was able to do very good phones with GC languages with very good performance for 200 euros, maybe Apple should talk to their runtime engineers.

Wasn't most of the system stack in C++ since it was shared with either Windows or Nokia? Either way, they went out of business, so we can't tell if they can support a phone 5 years back with new OS features.