21

Do I no longer have to worry about memory management iOS 5 onwards? Also, will all programs written for iOS 4 and earlier versions have to be rewritten to allow iOS to manage the memory for you?

NSExplorer
  • 11,849
  • 12
  • 49
  • 62

3 Answers3

39

You appear to be talking about Automatic Reference Counting, mentioned in other answers. ARC is a kind of GC in that it automates memory freeing, but has a number of differences from a good garbage collector.

Firstly, it's mainly a compiler technology. The compiler knows about Cocoa's reference-counting guidelines, so it inserts retains and releases where they should be according to the rules. It works just like if you'd written the retains and releases yourself — it simply inserts them for you. Normal garbage collectors keep track of your program's memory while it is running.

Second, since it is just like retain and release, it can't catch retain cycles (if Object A retains Object B and Object B retains Object A, and nothing else references either of them, they both become immortal). You need to take the same precautions to prevent them.

It also uses resources differently from an automatic garbage collector. The garbage collectors used with Objective-C have to scan for unreferenced memory and collect it — which is expensive, and can lead to "stuttering" on slower systems — but they only have to do this occasionally, and in theory can even fine-tune their collection cycles to match how a program actually uses its memory. In general, a GC program will use more memory than a non-GC program and will slow down significantly when the GC decides to collect. ARC, on the other hand, moves the "scanning" to compile-time and frees memory as soon as it's available, but it has to constantly update object reference counts instead of waiting for garbage to build up like a collector.

Chuck
  • 234,037
  • 30
  • 302
  • 389
  • Great stuff, thanks, @Chuck. "You need to take the same precautions to prevent them" as what? Meaning you need to avoid using "retain" properties on delegates, etc.? Also: will one declare properties as retain or assign at all? What about rewriting setters for a retain property, does the dev use `retain` then? – Dan Rosenstark Jul 17 '11 at 20:37
  • 1
    @Yar: Yes, avoiding retains on delegates is a big one. Rather than `assign`, though, you'll want to use `weak` for unretained properties. As for using `retain` in a setter: ARC mode makes it illegal to explicitly send `retain`, `release` or `autorelease`. You just assign and the compiler will insert retains and releases where it thinks they're necessary. – Chuck Jul 17 '11 at 22:09
  • Thanks @Chuck, helps a lot. So is this available with XCode or it's tied to the iOS 5 SDK? In other words, can you compile like this for iOS 4.x? I imagine not. – Dan Rosenstark Jul 18 '11 at 01:21
  • 2
    @Yar: The specifics of what versions it will be enabled for are under NDA and quite possibly subject to change, but it is a combination of a compiler feature and a runtime library that implements some of the functionality (particularly weak references). Currently there are two ways to use ARC: 1) Get Xcode 4.2 from the iOS developer program; or 2) Download a recent release of LLVM yourself and use that as your compiler. – Chuck Jul 18 '11 at 02:07
  • Thanks @Chuck, helpful as usual. I would LOVE to rip up my current project and ARC it, but I promise to start with a HelloWorld first :) – Dan Rosenstark Jul 18 '11 at 02:25
  • So was there any answer here as to whether it will work with iOS 4? – rogerdpack Jun 11 '13 at 15:54
  • 1
    @rogerdpack: http://stackoverflow.com/questions/7747783/is-arc-really-supported-in-ios-4-the-ios-4-2-sdk-is-missing-arc-related-symbols – Chuck Jun 11 '13 at 16:47
  • 1
    The last paragraph perpetuates many myths. "Garbage collectors have to scan for unreferenced memory and collect it — which is expensive". Tracing GC is much faster than reference counting. That's why JVM and .NET both use tracing GC. "and can lead to "stuttering" on slower systems". Real-time GCs exist. Incremental GCs are commonplace. "ARC, on the other hand, moves the "scanning" to compile-time". ARC bumps reference counts at run time. That's why it is so slow. "frees memory as soon as it's available". No it doesn't. – J D Feb 28 '15 at 17:47
  • @JonHarrop: I think I'd supposed people reading this comment would know that I'm talking about the garbage collectors used with Apple's Objective-C, not the .NET or JVM garbage collectors. If it confused you, though, I'll edit it to be more specific. AFAIK, no Objective-C garbage collector was faster than ARC in the average case, though they had significant wins in concurrent performance. – Chuck Mar 02 '15 at 22:43
23

On Apple's public iOS 5 page, they state:

Automatic Reference Counting

Automatic Reference Counting (ARC) for Objective-C makes memory management the job of the compiler. By enabling ARC with the new Apple LLVM compiler, you will never need to type retain or release again, dramatically simplifying the development process, while reducing crashes and memory leaks. The compiler has a complete understanding of your objects, and releases each object the instant it is no longer used, so apps run as fast as ever, with predictable, smooth performance.

It's a compiler feature; not an OS feature so I don't see why it wouldn't work with older versions.

Sophie Alpert
  • 139,698
  • 36
  • 220
  • 238
  • 4
    That's not garbage collection. – jscs Jul 04 '11 at 23:02
  • 5
    No, it's better than garbage collection. The compiler knows what needs to be released and when, so all memory management is taken care as if you did it yourself. Much more efficient than GC as it doesn't use resources while the app is running. – Brandon Schlenker Jul 04 '11 at 23:19
  • 5
    Expanding on Josh's point, this won't help if you have objects of a cyclical nature - ie, for the simplest case, 2 objects that refer to eachother with nothing else refering to them. Their reference counts will never decrease to zero and so they will not be removed. _Edit: @Brandon: in part why we use GC :p_ – Callum Rogers Jul 04 '11 at 23:19
  • 5
    @Brandon, *The compiler knows what needs to be released and when, so all memory management is taken care as if you did it yourself.* you mean it deals w/ cyclic references too? Either way, ref. counting is slower than a good garbage collector and it's very slow for multi-threaded code. – bestsss Jul 05 '11 at 00:27
  • @Callum Rogers, ARC would be totally useless if it can't handle that case. I'm NOT saying that it does (I don't know), but I would guess that it does (not sure how). On second thought (edit), see @Chuck's answer below. – Dan Rosenstark Jul 17 '11 at 18:57
  • 3
    @Yar: ARC is still reference counting — it's just automatic. Reference-counting algorithms aren't able to detect retain cycles. Cycle detection requires something more sophisticated and would incur more overhead at runtime. – Chuck Jul 17 '11 at 22:15
  • 2
    It also is a runtime feature in iOS5. iOS 4 has support for ARC except for zeroing weak pointers http://stackoverflow.com/questions/7246513/zeroing-weak-references-in-arc – Javier Soto Sep 15 '11 at 09:57
  • 1
    So again, if I have an app that I wrote for iOS 4, in which I implemented memory management (but say I had some leaks or something), do I have to do anything to get it to use ARC (such as removing the existing `release`s and `retain`s) or will it just do all of the ARC automatically? – Josh Sherick Nov 08 '11 at 18:33
9

Automatic Reference Counting implements automatic memory management for Objective-C objects and blocks, freeing the programmer from the need explicitly insert retains and releases.

You will worry less about memory management. There is public info available on the subject:

If the spec is too harsh to read, in short, you will need to edit the retain/release code to use ARC, but old programs remain compatible. What you shouldn't do is mix both.

Jano
  • 62,815
  • 21
  • 164
  • 192