To head off some of the misconceptions here, this is not about garbage collection in general but Objective-C built-in garbage collection.<p>Apple NEEDs to do this for their own sanity. I'm surprised they waited this long actually.<p>It's a serious PITA to support GC and non GC at the same time in a framework. Having to add finalizer methods instead of relaying on dealloc methods and dealing with non-deterministic object lifetime as well as deterministic was a huge problem.<p>ARC doesn't have these problems because it wraps traditional manual reference counting (to pick nits, it actually bypasses it when it can safely but this is an optimization detail that you shouldn't need to worry about).<p>To Apple and 3rd party framework developers, it's painful to support GC and non-GC paths in your code at the sametime. It's not really possible to use a non-GC compatible framework in a GC app.<p>It's also impossible to use ARC and still support the GC as well in the same framework. Apple has been completely <i>prevented</i> from using ARC in it's own frameworks because of keeping GC compatible apps working, and making this change will allow them to start ARC-ifying their own code.<p>It also means that a significant chunk of the ObjC runtime can be simplified.<p>There are also some great advancements in the ObjC runtime that Apple is doing (like tagged pointers and shadow objects) that the reference boehm garbage collector can't really deal with and was all completely disabled in the ObjC runtime when you had a GC app.<p>This is a good thing. Not many app actually shipped with the ObjC garbage collector and ran well.<p>Now you are free to use your GC for your own needs in your app. That has nothing to do with ObjC. Feel free to add Java or Ruby or whatever language you like to your own app and submit that to the Mac App Store.
What Apple calls "automatic reference counting" is what is usually known as just "reference counting." They call it "automatic" to distinguish it from the previous, even cruder, system where counts were manipulated directly by the programmer. Obviously this is an improvement, but personally I am a supporter of GC. It is a myth that reference counting is not subject to arbitrary pauses: <a href="http://www.hboehm.info/gc/myths.ps" rel="nofollow">http://www.hboehm.info/gc/myths.ps</a>
What is the reasoning behind that? Given the advances over the last decade or two automatic garbage collection is good enough for a lot of scenarios and this looks like a step back. Why not use automatic garbage collection as the default but offer additional means for manual resource management in case it is really needed?
I wonder how many applications will start leaking memory as a result of this? Cyclic references are not that uncommon in many algorithms, and identifying the need to remove these will be challenging for applications which relied on automatic identification will take time.
This is a pity. I have an app that uses ARC on 64bit, and GC on 32bit. Allowed me to ditch manual memory management without dropping support for 32bit machines.
Awesome. Now all they gotta do is stop treating strings like we're in a Pascal Intro to Computer Science class circa 1987 and we gots ourselves a kick ass development environment here. :)
What the fuck? This is a <i>really</i> bad technical decision. As written, it sounds like they're planning to reject garbage collection in-general, which would be a ban on most major programming languages. If you assume they only mean garbage collection in Objective C, it's still a head-scratchingly stupid decision. Modifying an app to not use garbage collection is, in many cases, a major project that will introduce a lot of bugs. And the benefit is... very dubious at best.