How do I replace weak references when using ARC and targeting iOS 4.0?

Question

I've begun developing my first iOS app with Xcode 4.2, and was targeting iOS 5.0 with a "utility application" template (the one that comes with a FlipsideViewController).

I read that since ARC is a compile-time feature, it should be compatible with iOS 4 as well, so I attempted to target my app to 4.3, and try compiling it. When I do so, I get this error:

FlipsideViewController.m: error: Automatic Reference Counting Issue: The current deployment target does not support automated __weak references

It is referencing this line:

@synthesize delegate = _delegate;

That variable is declared as:

@property (weak, nonatomic) IBOutlet id <FlipsideViewControllerDelegate> delegate;

I understand that "weak references" are not supported in iOS 4, but I don't really understand why I would want to use a weak reference to begin with, nor can I figure out how I would rewrite things to avoid using it, while still taking advantage of ARC (after all, it's supposed to work with iOS 4 AND 5 right?)

Hardhack

Answer 1

To target the older OS, you can use unsafe_unretained instead of weak in your property declaration, and it should mostly work the same way. weak references nil themselves when their target goes away, but unsafe_unretained leaves open the possibility that the object you're linking to could turn into a dangling pointer when it is deallocated. The latter is the same behavior as if you had used assign as a property declaration in manual memory management.

You do this to avoid retain cycles, which I mention in my answer here. You don't want to have a strong pointer to something that might have a strong pointer back to the original object. Then nothing would get released properly.

Khasi

Thanks for the advice. You say "to target the older OS...". Does this mean I should only use unsafe_unretained in builds of the app older than 5.0? Or can I just use unsafe_unretained in my code, and build it to target both 4.x and 5.x? – Hardhack

@Mason - unsafe_unretained is supported in both iOS 4.x and 5.0, so it gives you backwards compatibility. If you were doing a 5.0-only build, you might switch to weak to take advantage of the additional safety it gives you. – Khasi

I tried unsafe_unretained, it worked anyway. However, I got lot's of warning like '"** __NSAutoreleaseNoPool(): Object 0x564bd90 of class __NSArrayM autoreleased with no pool in place - just leaking"* ', that's normal? – Appellation

@Appellation - That's a totally unrelated issue. You're running something on a background thread without having an autorelease pool in place. Manually created threads do not have their own autorelease pool, so you need to create one yourself using @autoreleasepool (under ARC, NSAutoreleasePool for older manually reference counted implementations). – Khasi

@Brad, that's helpful, warnings're gone, I got several performSelectorInBackground calls. – Appellation

@Appellation - As a suggestion, you should really look at moving to blocks and GCD. Blocks dispatched on a background queue have an autorelease pool already in place for you, but more than that GCD can simplify your code and make your multithreading much more efficient. – Khasi

@Tejada - Your edit wasn't correct. Property attributes do not have the underscores that you edited into my answer. Those only apply to instance variables. – Khasi

@BradLarson My mistake, was using it for variables and realized it wasn't working. Figured you happened to overlook that so I made an edit. – Tejada

Answer 2

If only using weak references for additional safety, manually call the new runtime functions if they're available and fallback to simple assignment on __unsafe_unretained variables if not.

ZWRCompatibility.h will simplify this somewhat.

Histaminase

Answer 3

Thanks to Mike Ash's compatibility library PLWeakCompatibilty, you can now simply use __weak on iOS 4.x, as well.

It's incredibly easy to configure and requires no additional consideration or effort over 5.x.

Refection