Is modern Objective-C convention really to not have any ivars that aren't properties? [duplicate]

Question

Possible Duplicate:
iOS: must every iVar really be property?

I just read a book that said that modern convention is not to declare any ivars at all in your .h file between curly braces, and instead to make everything properties.

I want to make sure this is true even in trivial cases. I am making a class where there is a BOOL named "recording" which says whether the device is currently recording some video. This isn't something that other classes need, and my incline is to just put it as a BOOL in the header then refer to it in the .m file in the 2 spots where it is needed.

However, I also want to do things the accepted, right way. But I don't see why I make it a public property?

Answer 1

What you read is wrong, plain and simple.

Modern convention is to skip ivars when there is a corresponding property that can synthesize them. Additionally, with recent versions of LLVM it is possible to move your ivars to your implementation file (as @DrummerB has already mentioned) so that the header contains no ivars. That's considered good practice because it doesn't expose internal workings of the class.

But have no ivars at all and a property for everything that was an ivar? Nope, not normal Objective-C.

Answer 2

Your book is right (and wrong). Don't declare ivars in your headers anymore. That's only supported for compatibility reasons. But also don't declare properties for private variables.

If you want do declare a private ivar that other classes don't need to use, declare them in your implementation file:

// MyClass.m
@implementation {
    BOOL recording;
}

// methods

@end