Not really. Obj-C already had a GC and dropped it, to implement ARC because it's faster and more memory efficient.
GC was dropped from Objective-C, because Apple did not manage to make it work safely with C semantics.
Objective-C developers weren't able to mix Frameworks compiled with and without GC, there were lots of corner cases and forum discussions regarding GC runtime crashes were quite common.
Apple's decision in such scenario was to take the alternative route to make the compiler do what the Cocoa manual reference counting patterns already required.
Nothing to do with being faster and more memory efficient, rather having something in Objective-C that would work at all.
However this urban myth keeps being repeated.
There were definitely pain points, including C interop. But these could have been worked through. Apple is good at these sorts of transitions - think x86 or 64 bit, which had the same issues (can't mix 32 bit and 64 bit frameworks, etc).
Probably if Apple had not started making mobile devices, ObjC would have retained GC. But mobile devices had performance requirements that GCs struggle to meet. It's too broad to say that ARC is "faster and more memory efficient"; rather it's more efficient in the ways that are important to Apple. For example, avoiding pause times is more important than total allocation throughput (have to avoid dropped frames). Memory high-water-mark is more important than fragmentation. etc. Servers are the reverse.
Note that GC has been painful on all mobile platforms, not just iOS. That's why Microsoft has taken a step back from GC (WinRT uses ARC). And in Android, GC is one of the most common drivers of performance issues, and avoiding GCs is a key optimization technique. The compiler even warns on allocations inside functions like onDraw().
Android GC has been quite behind the state of the art from what production embedded JVMs like Aonix and Websphere Real Time are capable of. Actually Dalvik was left in limbo for quite awhile before they eventually came up with ART.
So it is easy to just generalize GC vs RC without regarding what algorithms are actually being used, and the qut of said implementations.
There are military weapons control systems and factory robots using real time GC implementations of Java in hardware much more constrainted than a smartphone.
It may be the embedded world has very advanced GCs that would perform well on modern mobile platforms, and just nobody has gotten around to integrating them yet. I don't know! But embedded devices with predictable workload that you can model and test are quite a different beast from a general-purpose computer, so that remains to be proven.
The outcome of Singularity and Midori is a proof of it, in spite of the outcomes prooven by their research, the projects were killed by management.
At least they allowed some of the tech to be repurposed for .NET Native.
>>Has a GC been considered at all? >GC [also] has several huge* disadvantages that are usually glossed over: while it is true that modern GC's can provide high performance, they can only do that when they are granted much more memory than the process is actually using. Generally, unless you give the GC 3-4x more memory than is needed, you’ll get thrashing and incredibly poor performance. Additionally, since the sweep pass touches almost all RAM in the process, they tend to be very power inefficient (leading to reduced battery life). I’m personally not interested in requiring a model that requires us to throw away a ton of perfectly good RAM to get an “simpler" programming model - particularly on that adds so many tradeoffs.*
So it's hardly "completely wrong", especially for iOS.
Referencing counting seems to be in vogue these days because it is somewhat more predictable on mobile systems, at least this is what I heard about the Metro/Store/UWP API at Microsoft (C# is still garbage collected, but the APIs are primarily ref counted).
If you search for Ext-VOS on Don Syme blog, it resembles quite a lot the genesis of .NET before they went with the CLR.