Apple’s ARC (automatic reference counting) for Mac and iOS devices is intended to make Cocoa development easier. For the most part it does. However, in using it I have encountered a bit of a pitfall: by default the compiler does not optimize your code in debugging but uses its most optimized setting for release. What does this mean? Well, the more you tell it to optimize your code, the sooner it will release objects for you, which can lead to some issues. To be clear the default settings for each mode are zero optimization and the most possible optimization respectively.
Basically, a lib I was using was working fine in testing but was throwing BAD_ACCESS errors when running in release mode. After over an hour and half of investigating I found:
The screenshot is showing XCode’s “Build Settings” screen, where you can clearly see that a different level of optimization is being used for the two different modes.
From here the fix is pretty easy: tune down that optimization level. Alternatively, you could dig into the code that is having the issues, but that might turn out to be something of a premature optimization for most needs.
Hope this helps someone. You can find me on Twitter or Google Plus.
ARC (short for automatic reference counting) is one of the most talked about and interesting additions to the iOS developer toolchain. However, in recent conversations with other developers I’ve found that there are a lot of misconceptions surrounding the technology. Hopefully, this clears up some of the confusion.
The first mistake that people often make when talking about ARC is that they equate it to garbage collection in languages such as C# and Java. This is simply incorrect. Boiling it down to its most basic explanation, a garbage collector runs in your application and checks to see what objects are no longer needed and removes them. This means that garbage collectors are very convenient for developers, but they take a small (depending on the implementation) amount of resources themselves. ARC is a special setting that can be set from within XCode that tells the compiler to insert release statements for you. So, this means that when you have ARC enabled the compiler is following the same retain / release rules you would normally follow for your own memory management, but this only happens at compile time, so there is no performance hit and you never see that statements themselves. This is useful because the compiler is far less likely to make a mistake than the average developer, especially in tricky situations, such as those that arise with multiple autorelease pools.
The second common belief developers hold surrounding ARC is that all their projects should use it. For new projects, this makes sense as long as you don’t mind targeting iOS 4.3+. However, converting legacy projects to use ARC can be a little hairy and like all magic that is made for developer convenience, when ARC causes a problem, it tends to be a tough one. Of course, that is not always the case and you mileage will certainly vary, but this is something to consider before hitting that shiny convert button.
Lastly, a number of developers that I have spoken to are under the mistaken impressions that all libs or external projects that you project is taking advantage of must be compatible with ARC for your codebase to use ARC. This is not the case. You can toggle ARC on and off for individual projects within your project (I know that sounds weird to me too) and safely use your legacy C libs or non-ARC Objective-C frameworks.
Overall, ARC is a great addition to the iOS developer’s toolbox, but it is like any other new technology and should be understood for what it is and adopted when appropriate.