Must every ivar be a property?

Solution 1:

It's not really necessary to declare properties for all ivars. A few points come to mind:

• If an ivar is only going to be assigned to once during the lifetime of the object, you don't really gain anything by declaring a property. Just retain/copy/assign during init and then release as necessary during dealloc.
• If an ivar is going to be changed frequently, declaring a property and always using the accessors will make it easier to avoid memory management errors.
• You can declare properties in a class extension in the .m file rather than the .h file if the properties and ivars are meant to be private.
• When targeting iOS 4.0+, you don't need to declare ivars at all in your header if you define a property and synthesize accessors.

So I generally use properties, but for things like a NSMutableArray that an object allocates during init and uses to hold a bunch of whatevers, I'll use a plain old ivar since I'll never be reassigning the ivar.

Solution 2:

While Daniel's answer is correct, I think it misses an important point. Namely:

I find that using properties instead of plain old ivars just takes too much code and I don't really see the benefits if you're comfortable with memory management.

The benefits are consistency; consistent memory management and consistent behavior.

Notably, these two lines of code can actually have extremely different behavior at runtime:

iVar = [foo retain];
self.iVar = foo;

The first is a direct setting of the instance variable and there will be no change notifications. The second goes through the setter and, thus, preserves any subclass customizations upon set and ensures that any observers of the property are notified of the change.

If you are using ivars directly throughout your code (internally to the class -- if you are using ivars of an instance directly from outside that instance, well... any contractor working on your codebase should double their rates ;), then you must either also handle change notification propagation manually (typically by calling willChangeValueForKey:/didChangeValueForKey) or explicitly engineer your application to avoid use of mechanisms that rely upon Key-Value Observation.

You say "takes too much code". I don't see that; in the above two lines of code, the dot syntax is fewer characters. Even calling the setter method using traditional syntax would be less code.

And do not discount the value in centralizing memory management; one accidental omission in a myriad of call sites and crash city.

Solution 3:

Property are just syntax sugar that avoid you to write same methods over and over. With a property you have a setter that release the old object and retain the new one for free.