One of the new developer APIs presented at WWDC was something called Automatic Reference Counting. This term also was on this slide visible during the Keynote, so it’s no longer a secret.
ARC might just be the single piece of technology which excited WWDC attendees the most. We cannot discuss the details of what was presented during the conference, but there is already quite a bit of public information available. Enough to get every iOS developer excited.
There are basically two modes of memory management:
- Garbage Collection – frequently a process – the garbage collector – scans for objects that are not used any more and those are freed
- Reference Counting – each object has a counter that gets increased whenever another object needs it and decreased when it no longer needs it. Objects are freed when their counter reaches 0.
The former is the prevalent mode in desktop systems. The latter is what we use in Objective-C nowadays, with the addition of autorelease pools which might be seen as sort of a manual garbage collection done every time the run loop is entered: all objects marked for autoreleased are sent a release once. This way you don’t have the overhead of walking through all objects, but still you have a bit less to worry about.
The technical explanation of what ARC is can be found in the official CLANG LLVM ARC documentation. It summarizes it like this:
Automatic Reference Counting implements automatic memory management for Objective-C objects and blocks, freeing the programmer from the need explicitly insert retains and releases.
Yes, you see it right! No more retains and releases! Isn’t that fabulous?
Poster courtesy of Joshua Kennedy (@deadmeta4)
ARC adds “Automatic” to the process of reference counting so that we don’t have to worry about it any more. Think of what Build&Analyze already does when it shows you where you are overreleasing or underretaining something. The think how great it would be if it would actually also correct your code automatically. ARC does exactly that and quite a few things more.
Think of ARC like the movie coming next year where just seeing the trailer gets you excited. Awesome special effects! Cool story! Great acting. And so much more that the trailer cannot give away all of the plot.
Those are the items that we cannot discuss: when or how Apple will enable ARC for public use and discussion. It might or might not be in a future version of a compiler or development tool … if you catch my drift. But putting it in this front and center position of the above mentioned slide tells us developers that ARC will be daily business for us once we get to develop solely for iOS 5.
Poster courtesy of Lukas Burgstaller (@voidStern)
I think that it’s rather “typically Apple”: if you have two technologies that both have their indy-vidual advantages and drawbacks, then Apple will just go and invent a third option that has only advantages. One of the more immediate ones will mean that most iOS development courses can be one day shorter because we no longer have to explain retain/release to beginners. “It just works!”
ARC is one of the new technologies that make me wish that I can soon switch to only be developing on iOS 5. I don’t know yet if you will also be able to build for iOS 4 with ARC. May be, may be not. Please comment if you know more that’s not under NDA.
Thank you to Lukas and Joshua for providing the two movie posters I’ve included in this article. Both are accomplished designers of iOS apps, and were incredibly fast in implementing my ideas. You should contact them via the provided links if you need their services.
Categories: Apple
as i heard it will be backwards compatible, because the counting happens on compiler level. so you should be fine with ios4
I feel all giddy inside now
“The latter is what we use in Objective-C nowadays”
Er no, well not only. Garbage collection is also used in Objective C since OS X Leopard. It just has never been ported to iOS (and now we know why)
I don’t think you will soon be switching to only iOS 5. What about all those users who cannot switch to the new iOS.
I have an App that still supports 3.1.3 because a number of users cannot upgrade their extremely old ipod touches to a newer iOS. I have an old iPhone 3G that cannot upgrade to iOS 4.3. Are all these buyers of my Apps to be abandoned just so I can use ARC?
If I continue to support the current Apps and only make my new Apps ARC compatible then only those with iOS 5 will be able to buy them. So I have lost a lot of potential customers.
Finally, I have also done some Mac OS X Apps. I did, initially, enable garbage collection but then turned it off again because it meant I would have to remember to use retain/release for my iOS Apps and then not use it for my Mac OS X Apps. I have enough trouble remembering when to use them and when to not so I stuck with what iOS wants and Mac OS X is happy to use.
Now, iOS will have ARC and this will confuse the issue more. I think I will stay with retain/release.
P.S. I do not like retain/release I much prefer garbage collection.
You can build for iOS 4 with ARC. Quote from Apple engineer: “For iOS 4 and Mac OS 10.6, the compiler adds a bit of runtime compatibility glue code to your app. This works for everything except __weak variables, which require more support than the compatibility code can provide. ARC on iOS 4 is simpler than non-ARC code, but it’s not as simple as ARC on iOS 5.” By the way, the WWDC schedule app was written with ARC and it worked on iOS 4 just fine!
http://stackoverflow.com/questions/6308425/ios-5-best-practice-release-retain
“So I have lost a lot of potential customers.”
A lot? I don’t think so. Most users will upgrade. Those who won’t bother to upgrade would probably never buy your app anyway. And those who can’t upgrade because they have an unsupported device are a tiny minority. Users usually upgrade when their device becomes unsupported. Just check the figures. Who still owns an iPhone pre-3GS nowadays? Maybe 2% of users — and even if it’s thrice that figure, that’s not what I call “a lot”.
Sorry by a lot I was not talking percentages I really meant numbers. 2% of 100 million devices is 2 million devices. Now if 90% of Apps won’t work on their device because they cannot upgrade to the new iOS then my App is at an advantage because it does support their device.
Also, as stated I have a 3G iPhone and will only upgrade when it breaks.
Plus, when someone upgrades to a new iPhone 4 where does their iPhone 3G go? Someone buys it and wants Apps for it. Once again I am at an advantage. My App will work on their old phone many others will not.
One major problem with the App Store is getting you App noticed I think having it support 3.2 onwards is something that will get you noticed.
This isn’t actually garbage collection. You can kind of pretend that it is, as long as you use standard functions in a standard way. Mostly. That should work reasonably well. Except when it doesn’t.
I’m not sure what details are covered under NDA so I’ll be vague.
There were a number of corner cases and interactions with older technologies that will cause problems. They are aware of them, since they brought them up, but still.
It’s generally a positive move. I usually write with the alloc/init/autorelease pattern just because memory management often gets messed up after I hand code over to a client. For new projects I can just leave that out and be careful.
For older projects, particularly things that interact with older technologies (Apple ones, mind you) or that use 3rd party libraries…. ugh. I foresee some emergency memory debugging for clients in my future.
The WWDC schedule app was, um, a bit crashy.
I abandoned ARC within a few hours. ARC has great potential (in theory) but in practise I vastly prefer doing the memory management manually.