I'd love to read some commentary by someone who's really intimately familiar with the iPhone and its internal workings about the rationale for not having a garbage collector. I've seen Apple refer to performance, but.. how big an effect is it, really? If anyone here wants to have a shot at explaining it, go ahead! :)

Well, its only got 128MB ram and flash storage...so there is no virtual memory I suspect. I'm sure the OS takes a big chunk of memory, with the possibility of background tasks eating up more. With a garbage collected system, I'm sure you'd routinely see performance hits when the garbage collector runs as it frantically tries to free storage with low and fragmented memory conditions. Not to mention the extra battery drain to constantly scan the freeable pointers. This is an embedded device with big limitations...you need to be more mindful of resources.

Windows Mobile supports garbage collection in Compact Framework without any hiccups and with less RAM (64Mb).

One could argue that WM does not have such rich applications, but to that I have two counter-arguments: 99% of iPhone apps not rich in functionality and therefore number of objects. Fatness of iPhone apps comes from graphics, not from large number of objects and GC should not be negatively affected.

My theory of all this is that Apple is taking things step-by-step, adding each feature only as it matures. Writing a good GC takes a lot of expertise and effort. It's an extra challenge that ObjC is not a managed language, unlike CLR-based languages.

There's already a garbage collector in the Objective-C runtime for regular Mac OS X. People targeting OS X 10.5 and higher (that's anyone writing a new app) are happily using it.

They've just chosen not to enable its usage on the iPhone.