Difference between _ and self. in Objective-C

Question

Is there a difference between using the underscore and using the self keyword in Objective-C when calling an @property?

Property declaration:

@property (weak, nonatomic) NSString *myString; 

Calling @synthesize on the property:

@synthesize myString = _myString; 

Is there a difference if I want to use it in my code? When? In the getter/setter?

self.myString = @"test"; _myString = @"test"; 

Answer 1

self.myString = @"test"; is exactly equivalent to writing [self setMyString:@"test"];. Both of these are calling a method.

You could have written that method yourself. It might look something like this:

- (void)setMyString:(NSString*)newString {     _myString = newString; } 

Because you used @synthesize, you don't have to actually bother writing that method, you can just allow the compiler to write it for you.

So, from looking at that method, it looks like calling it will do the exact same thing as just assigning a value to the instance variable, right? Well, it's not so simple.

Firstly, you could write your own setter method. If you do so, your method would get called, and it could do all sorts of additional things as well as setting the variable. In that case, using self.myString = would call your method, but doing _myString = would not, and thus different functionality would be used.

Secondly, if you ever use Key Value Observing, the compiler does some very clever tricks. Behind the scenes, it subclasses your class, and overrides your setter method (whether it's one you wrote yourself or one generated by synthesize), in order to make the calls to willChangeValueForKey: that are needed for Key Value Observing to work. You don't need to know how this works (although it's quite interesting if you want some bedtime reading!), but you do need to know that if you want Key Value Observing to work automatically, you have to use setter methods.

Thirdly, calling the setter method even if you're relying on synthesize to write one gives you flexibility for the future. You might want to do something extra whenever a value is changed, and at the point you discover you want to do that, you can manually write a setter method — if you're in the habit of always using self.myString =, then you won't need to change the rest of your code to start calling the new method!

Fourthly, the same applies to subclasses. If someone else was to subclass your code, if you use the setters then they could override them to adjust the functionality.

Any time you access the instance variable directly, you're explicitly not providing a way for extra functionality to be hooked in at that point. Since you or someone else might want to hook in such functionality in the future, it pays to use the setters all the time, unless there's a good reason not to.