Difference between declaring an ivar in @interface and putting variable in @implementation

Question

What is the difference between declaring an ivar within an @interface versus putting a variable within an @implementation in a .m file?

Answer 1

As far as I know, putting a variable declaration inside the @implementation is no different from putting it outside the implementation: It's not an ivar, it's just a variable declared at file scope.

One use is for declaring the equivalent of C++ static members. For example:

@implementation MyClass

static int s_count = 0;

- (id)init {
  if ((self = [super init]))
    ++s_count;
  return self;
}

- (void)dealloc {
  --s_count;
  [super dealloc];
}

Assuming init is your only initializer, then s_count will contain the total number of instances of MyClass that are active.

Answer 2

Note: Historically, the interface required declarations of a class’s instance variables, the data structures that are part of each instance of the class. These were declared in braces after the @interface declaration and before method declarations:

Instance variables represent an implementation detail, and should typically not be accessed outside of the class itself. Moreover, you can declare them in the implementation block or synthesize them using declared properties. Typically you should not, therefore, declare instance variables in the public interface and so you should omit the braces.

(source)

Answer 3

The difference between using an ivar and declaring a variable inside the implementation is that the variable within the implementation is at file scope and global. That means all instances (and any static methods) will share the same variable; i.e. if one instance of your object changes the variable, it will change it for all instances.

The use case for defining it at file scope is to store things for static methods (methods that act directly on the class instead of an instance of the class). A really common use case for this is the Singleton design pattern. You can define a static instance of your class within this file so that at any time, you can ensure you are accessing the same instance. You can provide a static method that returns this instance so any object in your code can access that same object by calling the method directly on your class.

Update 4/17/14

Common practice now is to use Properties. This creates getters and setters for you automatically making the class more extensible (if you decide to change the way a property works, perhaps you want to change it to always be calculated on the fly, the public interface of the class does not need to change).

You can use private class extensions to declare "private" properties and methods. This has the effect of protecting certain properties and methods from being accessed by outside classes.