Declaration/definition of variables locations in ObjectiveC?

I can understand your confusion. Especially since recent updates to Xcode and the new LLVM compiler changed the way ivars and properties can be declared.

Before "modern" Objective-C (in "old" Obj-C 2.0) you didn't have a lot of choices. Instance variables used to be declared in the header between the curly brackets { }:

// MyClass.h@interface MyClass : NSObject {    int myVar;}@end

You were able to access these variables only in your implementation, but not from other classes. To do that, you had to declare accessor methods, that look something like this:

// MyClass.h@interface MyClass : NSObject {    int myVar;}- (int)myVar;- (void)setMyVar:(int)newVar;@end// MyClass.m@implementation MyClass- (int)myVar {   return myVar;}- (void)setMyVar:(int)newVar {   if (newVar != myVar) {      myVar = newVar;   }}@end

This way you were able to get and set this instance variable from other classes too, using the usual square bracket syntax to send messages (call methods):

// OtherClass.mint v = [myClass myVar];  // assuming myClass is an object of type MyClass.[myClass setMyVar:v+1];

Because manually declaring and implementing every accessor method was quite annoying, @property and @synthesize were introduced to automatically generate the accessor methods:

// MyClass.h@interface MyClass : NSObject {    int myVar;}@property (nonatomic) int myVar;@end// MyClass.m@implementation MyClass@synthesize myVar;@end

The result is much clearer and shorter code. The accessor methods will be implemented for you and you can still use the bracket syntax as before. But in addition, you can also use the dot syntax to access properties:

// OtherClass.mint v = myClass.myVar;   // assuming myClass is an object of type MyClass.myClass.myVar = v+1;

Since Xcode 4.4 you don't have to declare an instance variable yourself anymore and you can skip @synthesize too. If you don't declare an ivar, the compiler will add it for you and it will also generate the accessor methods without you having to use @synthesize.

The default name for the automatically generated ivar is the name or your property starting with an underscore. You can change the generated ivar's name by using @synthesize myVar = iVarName;

// MyClass.h@interface MyClass : NSObject @property (nonatomic) int myVar;@end// MyClass.m@implementation MyClass@end

This will work exactly as the code above. For compatibility reasons you can still declare ivars in the header. But because the only reason why you would want to do that (and not declare a property) is to create a private variable, you can now do that in the implementation file as well and this is the preferred way.

An @interface block in the implementation file is actually an Extension and can be used to forward declare methods (not needed anymore) and to (re)declare properties. You could for instance declare a readonly property in your header.

@property (nonatomic, readonly) myReadOnlyVar;

and redeclare it in your implementation file as readwrite to be able to set it using the property syntax and not only via direct access to the ivar.

As for declaring variables completely outside of any @interface or @implementation block, yes those are plain C variables and work exactly the same.

First, read @DrummerB's answer. It a good overview of the whys and what you should generally do. With that in mind, to your specific questions:

#import <Foundation/Foundation.h>// 1) What do I declare here?

No actual variable definitions go here (it's technically legal to do so if you know exactly what you're doing, but never do this). You may define several other kinds of things:

• typdefs
• enums
• externs

Externs look like variable declarations, but they're just a promise to actually declare it somewhere else. In ObjC, they should only be used to declare constants, and generally only string constants. For instance:

extern NSString * const MYSomethingHappenedNotification;

You would then in your .m file declare the actual constant:

NSString * const MYSomethingHappenedNotification = @"MYSomethingHappenedNotification";

@interface SampleClass : NSObject{    // 2) ivar declarations    // Pretty much never used?}

As noted by DrummerB, this is legacy. Don't put anything here.

// 3) class-specific method / property declarations@end

Yep.

#import "SampleClass.h"// 4) what goes here?

External constants, as described above. Also file static variables can go here. These are the equivalent of class variables in other languages.

@interface SampleClass()// 5) private interface, can define private methods and properties here@end

Yep

@implementation SampleClass{    // 6) define ivars}

But very rarely. Almost always you should allow clang (Xcode) to create the variables for you. The exceptions are usually around non-ObjC ivars (like Core Foundation objects, and especially C++ objects if this is an ObjC++ class), or ivars that have weird storage semantics (like ivars that don't match with a property for some reason).

// 7) define methods and synthesize properties from both public and private//    interfaces

Generally you shouldn't @synthesize anymore. Clang (Xcode) will do it for you, and you should let it.

Over the last few years, things have gotten dramatically simpler. The side-effect is that there are now three different eras (Fragile ABI, Non-fragile ABI, Non-fragile ABI + auto-syntheisze). So when you see the older code, it can be a little confusing. Thus confusion arising from simplicity :D

I'm also pretty new, so hopefully I don't screw anything up.

1 & 4: C-style global variables: they have file wide scope. The difference between the two is that, since they're file wide, the first will be available to anyone importing the header while the second is not.

2: instance variables. Most instance variables are synthesized and retrieved/set through accessors using properties because it makes memory management nice and simple, as well as gives you easy-to-understand dot notation.

6: Implementation ivars are somewhat new. It's a good place to put private ivars, since you want to only expose what's needed in the public header, but subclasses don't inherit them AFAIK.

3 & 7: Public method and property declarations, then implementations.

5: Private interface. I always use private interfaces whenever I can to keep things clean and create a kind of black box effect. If they don't need to know about it, put it there. I also do it for readability, don't know if there are any other reasons.