Tips for iOS Developers: Use the Tools
Developers are often hesitant to use new or unfamiliar tools. We like code. We understand code, and we understand the things that we build from code. When our tools start to automate the coding process—taking control out of our hands and hiding it behind a slick, GUI interface—we tend to get a bit nervous. This leads many developers, both new and experienced, to avoid or ignore the tools that Apple has provided. Most of the time, this is a mistake.
Yes, some of these tools do require an investment in both time and energy before you can use them properly. Yes, none of these tools is without their drawbacks. However, in the long run, becoming familiar with these tools and using them properly will let us develop software more quickly, will reduce the number of bugs in our projects, and will make it easier to maintain our codebase.
Most importantly, however, by using the tools we are positioning our project for the future. No one knows exactly what Apple has planned; however, I guarantee that they will continue to build on the tools and frameworks that they have already developed.
Every developer should at least know how to use five key tools. In my opinion, you should use these on any new project—especially projects targeting iOS 7. You should also strongly consider porting over older projects as quickly as possible.
ARC
ARC, or Automatic Reference Counting, is a compiler feature that automatically manages memory management in Objective-C.
Traditionally, Objective-C has used manual reference counting to track the lifecycle of objects. When objects are created, they start with a reference count of one. If you want to hold onto an object, you call retain. This increases the reference count. When you’re done, you call release. This decreases the reference count. If the reference count ever hits zero, the object is deallocated.
ARC uses the same basic procedure, but instead of having the developer manually manage the memory, it automatically analyzes the code and adds the required retain, release and autorelease calls at compile time. It also optimizes the allocation, deallocation and memory management code. This is one of the incredibly rare cases in software engineering where we have a tool that both makes our lives easier while also improves performance.
Compared to manual memory management, ARC code is cleaner and removes entire categories of bugs. The bottom line is, to do effective manual memory management, the developer must be 100% correct, all the time. Even one small mistake could cause serious memory errors. Unfortunately, the human brain is just not designed to handle repetitive, detail-oriented tasks with perfect accuracy. On the other hand, this is exactly the sort of thing at which compilers excel.
I have a lot of anecdotal evidence that shows ARC’s effectiveness. I teach a lot of beginning iOS classes. In these classes, we create a relatively simple project using manual memory management, just to make sure the students understand what’s going on under the hood. Invariably, when we test these projects, we almost always find at least one memory-related bug.
Now, ARC won’t protect you from every possible memory-related problem. We still have to avoid retain cycles. We still have to make sure our application isn’t allocating too much memory or holding onto memory that it no longer needs, and we still need to make sure we have strong references to any objects that we want to access outside the current method. But all of these problems are equally true for manually managed memory. ARC doesn’t solve them, but it also doesn't make them any worse.
Furthermore, ARC’s Zeroing Weak References help prevent dangling pointers by setting any weak references to an object to nil when that object is deallocated. And, honestly, dangling pointers are a much more serious error than a simple memory leak. Manually managed memory simply does not have anything that can duplicate this feature.
At this point, ARC is a mature technology, and there’s no good reason to avoid using it. Developer brain power is a limited resource, and it’s better spent solving real problems than manually tracking memory.