Take the 2-minute tour ×

I am a new cocoa developer coming from a C#/Java background. I had been introduced to memory management patterns which objective-c language uses and I just find them very helpful for code-conscious development.

Why does Apple now want us to use ARC (Automatic Reference Counting) instead of MRR (Manual Retain-Release) and what advantages other than time saving does ARC offer?

I see such a transition negatively affecting good-citizen habits that developers gain from the obj-c ecosystem.


share|improve this question
Thanks @pst for the the editing. That was my first post and I forgot to further explain new acronyms. –  Nicholas E. Credli Dec 18 '11 at 21:56

3 Answers 3

up vote 11 down vote accepted

It's unfortunate that making it easier for competent developers to be correct has a side effect of making it easier for new developers to not learn, but it seems like it's probably worth it.

ARC is less forgiving than a tracing collector like C# or Java use though. If you don't have a clear object ownership model you will almost certainly create cycles and leak tons of memory. My hope would be that this is made obvious enough (via Instruments? That still requires seeking it out... not sure what could be done here) that new developers will quickly learn to keep their object graph clear and acyclic.

share|improve this answer
Thanks @Catfish_Man, I would rather prefer ARC being more like a compiler warning system supported by the static analyzer. –  Nicholas E. Credli Dec 18 '11 at 22:04
@NicholasE.Credli: It's strict on purpose: Most of the ARC rules are borne out of the principle that the compiler must be right 100% of the time, so when you throw it a case that's ambiguous, it will not guess what you mean but simply throw an error. The solution is simply to make your code unambiguous. –  Peter Hosey Dec 19 '11 at 4:18

ARC allows me to concentrate on writing useful code instead of boilerplate dealloc methods.

Most people I know have used autorelease behind every alloc anyway, because it saved you a release later and you couldn't forget to actually put it. So the object was around until the autorelease pool was drained, and with ARC the object gets deallocated when it isn't needed anymore. I think in those cases the ARC-compiled program will even use less memory.

And, shame on me, it helps me to make my apps crashing less often too.
That premature release that happens every 10.000 launches. The one that I could never track down completely, hopefully with ARC this is a thing of the past.


probably in the same way an embedded developer who started with assembler thinks people that start with C and have never used assembler get into bad habits.

In my opinion the MRR vs ARC discussion is similar.
ARC and C both allow to write more maintainable code in a shorter time. And both of them can lead to a larger memory and cpu footprint.
If I remember correctly Apple announced that they did add a little speed up to retain and release to compensate that impact on cpu usage. And because of that there is no real reason that MMR is still around.

I, for one, welcome our new ARC overlords.

share|improve this answer

i've actually rather enjoyed moving to ARC - it's one less thing to think about. on top of that, i think newcomers would often be tripped up by the significance of naming conventions (+alloc, -copy etc vs [NSString stringWith....]). the only tricky bit is when you start dealing with CoreFoundation etc (the C APIs) where you still have to keep in mind just who is owning what.

share|improve this answer

Your Answer


