Forget about retain and release, welcome to ARC (I)

One of the first things you learn after landing into iOS and Objective C is that garbage collecting (GC from now on) is evil. It is not really evil in itself, but performance wise and specially when facing user interaction you take for granted a few things: scroll shouldn’t shutter and lag must be confined. Your users don’t deserve less than that!

Memory management is tedious, and most interpreted, dynamic languages developers don’t deal with it directly. For C/C++ and most compiled languages developers is bread and butter, but it costs time and effort to get it right, and introduces bugs that tend to appear when a product goes in production. In MacOS X, the Cocoa runtime implements GC for easing the pain of retain and release cycles.

Whereas this approach works for a desktop-size machine, in an embedded system is not that straightforward. As most Android and Java developers will acknowledge GC kicks in the most inconvenient times, usually when the impact on the user experience is most noticeable - when some screen refreshing is triggered. Google is known to have been working on improving this for a long time, but still requires at least some CPU horsepower to minimize it.

Apple decided they wouldn’t be delivering a GC for iOS in the near future. Still, writing memory management code is cumbersome and prone to errors. Their answer comes from the hands of LLVM, the new alternative compiler to GCC that Apple has been working on for the last years. Long story short, it sits between the classical GCC architecture (while flexible, impedes some types of optimizations and makes it difficult to provide feedback to the IDE) and the CLR/JVM compilers targeting virtual machines. The analysis feature of XCode is based on this new compiler and provides developer with the usual catch-ups on memory management, mostly leaks.

I imagine someone asked: well if we could detect leaks with this systems, couldn’t we also fix them? Or even better, track the code paths so that we don’t need memory management at all. Moreover, we won’t need a runtime to do so (á lá GC) so no user experience impact will come from it. And so ARC was born.

First the disclaimer: at the time of this writing, LLVM 3.0 and ARC are only available for iOS5 SDK, so until GM is released you shouldn’t code with it for production projects, as you won’t be able (in principle) to submit code to the AppStore developed this way. But of course you can think of the future and start learning to use it as we are doing here at Sharewire.

During this series of posts I’ll be assuming the reader is familiar with iOS development, memory management and general development background.

So, how does it looks like?

At this point you are sick of writing retain and release cycles, creating autorelease pools for threads and getting sure that the ownership of the objects you create are already there. For more advance programmers, memory zones and zombies are somewhat of a pain. Well, forget about them. The most simple idea behind ARC is just to replace the usual qualifiers for properties (i.e. assign and retain) for strong and weak. This of resembles of some other languages, but in a nutshell you just have to specify whether you would like to keep the object assigned to the property in memory during the life time of the object for which this property is defined.

Additionally, it’s up to the compiler to keep track of the retain count for the objects you create (sort of, as this operation is performed in compile time). Please note that there is no magic behind this, the compiler is just smart enough to add the retain and release operations required to avoid memory leaks. Think of it being the same of synthesized properties: you just instruct the compiler to create the setters and getter, the same idea applies to retain and release cycles. The memory count is still kept but you don’t have to deal with it.

It’s not only that: you can’t manually retain and release objects once the project is enabled for ARC. Nor you are supposed to call the super call dealloc method or even use it.

Autorelease pools is a similar story. The autorelease pools are not created explicitly anymore, but you instruct the compiler (via a new at sign operator) to create and flush them. Really convenient in a sense, but again think of it of a shortcut as the pools still exists during runtime, you just don’t have to deal with them directly anymore.

The last nice thing that XCode adds is the possibility to convert you current projects to ARC – the IDE provides a refactoring tool to fix a whole project to the new scheme, making the whole process painless and quick.

Although I’m leaving things in the drawer, please let me finish this introduction to ARC here. In following articles we will describe in depth how to save up some precious coding time by using this new tool.