The important point about reference counting on idevices is the near realtime performance, since stops for collecting garbage are actually very short in comparison to collecting compilers (despite more frequent). Some compilers, I think it was for the pure functional programming language OPAL if I'm not wrong even check at compile time and add code for reusing cells instead of freeing them when it is known to be safe. But OPAL has strict evaluation and no lazy construct. This it does not allow for cycles unlike haskell which makes reference counting a viable and easy implementable option for OPAL. About Apple's ARC. It is actually using the very same mechanisms the clang static analyzer uses. That is at a first stage it works with the typical Objective-C conventions of object ownership. For example if you have a function other than alloc and Co. transferring object ownership to it's caller the static analyzer will complain about a possible space leak. In this case one has to add an attribute to the function telling the compiler that it is intended for the function to work like this. Having a look at the ARC docs it seems to be the very same case. That is if you have a function like just mentioned you need to add this said attribute to the function declaration for ARC to insert correct retains/releases. So there is no real magic going on, but one needs to be really aware of it or bug hunting (especially for external libraries) may become.... maybe a little less funny... Additionally clang adds some extra commands into the generated LLVM code which LLVM understands. This allows i) for further optimizations at later compiling stages and ii) you don't need to send messages to objects anymore for reference counting (as long as you don't implement retain/release for them by yourself, but by convention you don't do so...), but the counter may be accessed directly in memory. That's why ARC (if you follow Apple's conventions about object ownership) can be much more efficient than the current implementation. - Steffen