With gc enabled, [autoreleasePool drain] asks the gc to run (IIRC), with gc disabled, it releases everything currently owned by the pool. Even on the Mac, you may still want to build your app without gc for performance reasons, and Apple gives you that option.
I'm sure we'll see gc on iOS devices eventually, but it's probably too memory hungry to be practical on the phone right now.
The drain method releases the pool itself — it's precisely equivalent to release. This does release the objects in the pool as well, but a lot of people seem to think that drain leaves the pool valid. (The reason it was introduced is so the same method could be used in non-GC and GC code, where release is turned into a noop.)
Either that, or the objC gc isn't ready for a phone-constrained environment yet. Android seems to manage OK, but they put in a lot more up-front work into making it viable there.
Comments
With gc enabled, [autoreleasePool drain] asks the gc to run (IIRC), with gc disabled, it releases everything currently owned by the pool. Even on the Mac, you may still want to build your app without gc for performance reasons, and Apple gives you that option.
I'm sure we'll see gc on iOS devices eventually, but it's probably too memory hungry to be practical on the phone right now.
The drain method releases the pool itself — it's precisely equivalent to release. This does release the objects in the pool as well, but a lot of people seem to think that drain leaves the pool valid. (The reason it was introduced is so the same method could be used in non-GC and GC code, where release is turned into a noop.)
Either that, or the objC gc isn't ready for a phone-constrained environment yet. Android seems to manage OK, but they put in a lot more up-front work into making it viable there.