iOS Automatic @Synthesize Without Creating an Ivar

iOS automatic @synthesize without creating an ivar

In my working with this, I've noticed the following behavior.

If you have a readwrite property, don't have a @synthesize, have a getter and don't have a setter, then it will generate the iVar.
If you have a readwrite property, don't have a @synthesize, don't have a getter, and have a setter, then it will generate the iVar.
If you have a readwrite property, don't have a @synthesize and have both a getter and a setter, then it will not generate the iVar.
If you have a readonly property, don't have a @synthesize and don't have a getter, then it will generate the iVar.
If you have a readonly property, don't have a @synthesize and have a getter, then it will not generate the iVar.

From this, I think the general rule is that if you don't have a @synthesize, and have all the methods needed to fully implement the property, then it's assumed to be dynamic and doesn't generate the iVar.

At any rate, if you want to ensure that an iVar is not generated then declare it as @dynamic.

Clarification on @dynamic

From Declared Properties in The Objective-C Programming Language:

You use the @dynamic keyword to tell the compiler that you will fulfill the API contract implied by a property either by providing method implementations directly or at runtime using other mechanisms such as dynamic loading of code or dynamic method resolution.

To me this reads like it OK to mark a property as @dynamic even when you are directly implementing the getter and setter.

iOS 7 Dev - @synthesize not auto creating ivars

you can just skip the @synthesize completely, and it will create underscored ivars. If you do @synthesize without specifying the variable name (@synthesize firstName = _firstName;), it will create variables without underscores.

Declaring ivars in superclass or @synthesize in subclass?

If you want to use an ivar in both the superclass and the subclass, you have to declare it in the interface of the superclass, because it's the only file that's included in both implementations. Otherwise, you're just trying to guess what could be in the implementation of the superclass and xcode will not play game.

The above is true whether there is a property that use that ivar or not.

Now if you have a property in the superclass and you write in the subclass implementation :

@synthesize propertyName = _propertyName

You're just saying that you're ditching whatever implementation of that property was in the superclass and you want the standard setter and getter generated by xcode, working on an ivar named _propertyname. Maybe the superclass works the same way, maybe not.

Objective-C - readonly properties not synthesized with underscore ivar?

A property is not automatically synthesized if you implement all required accessor methods (getter for a read-only property, getter + setter for a read-write property).

Because you implement the getter method -(NSString *)myString for the read-only property,
it is not auto-synthesized. If your getter needs an instance variable to backup the property value, you have to add the synthesize statement (as you did) or an instance variable.

Why do I need to write @synthesize when I provide getter and setter?

When you provide both getter and setter, there is often just no need for an instance variable at all, i.e. when you just forward those messages or store data in other places.

As soon as one of them is missing, the ivar is needed to synthesize that functionality.

If I remember correctly, for readonly properties the analogue assumption holds as well.

why protocol can have @property but not iVar?

when you add a protocol you are just saying that who want implement that protocol must provide the same property or a set/get for that variable.

If your protocol "require" a property and your class doesn't provide it you will receive a warning

Auto property synthesis will not synthesize property 'varname' declared in protocol 'protocolname'

Should I continue to use iVar and @property (nonatomic, retain) plus @synthesize under Automatic Reference Counting (ARC)?

Don't feel like a doop, even though the compiler will add ivars for you if you don't include them, many people still declare them (many book authors as well) to make the code a little bit easier to read (easier to distinguish between ivar and property).

When creating a property now, Apple wants you to think in terms of Object Graphs, so do some research on "strong" and "weak" property attributes instead of retain and releases.

Also, iOS 4 is setup as a target for ARC so you should be ok. But I believe if you wanted to support iOS 3.0 you would have to manually manage retain and releases as before.

When should I use @synthesize explicitly?

There's a lot of answers, but also a big confusion. I'll try to put some order (or increase the mess, we'll see...)

Let's stop talking about Xcode. Xcode is an IDE. clang is a compiler. This feature we are discussing is called autosynthesis of properties and it's an Objective-C language extension supported by clang, which is the default compiler used by Xcode.

Just to make it clear, if you switch to gcc in Xcode, you won't benefit from this feature (regardless from the Xcode version.) In the same way if you use a text editor and compile using clang from the command line, you will.
Thank to autosynthesis you don't need to explicitly synthesize the property as it will be automatically synthesized by the compiler as
```
@synthesize propertyName = _propertyName
```
However, a few exceptions exist:
- readwrite property with custom getter and setter
  when providing both a getter and setter custom implementation, the property won't be automatically synthesized
- readonly property with custom getter
  when providing a custom getter implementation for a readonly property, this won't be automatically synthesized
- @dynamic
  when using @dynamic propertyName, the property won't be automatically synthesized (pretty obvious, since @dynamic and @synthesize are mutually exclusive)
- properties declared in a @protocol
  when conforming to a protocol, any property the protocol defines won't be automatically synthesized
- properties declared in a category
  this is a case in which the @synthesize directive is not automatically inserted by the compiler, but this properties cannot be manually synthesized either. While categories can declare properties, they cannot be synthesized at all, since categories cannot create ivars. For the sake of completeness, I'll add that's it's still possible to fake the property synthesis using the Objective-C runtime.
- overridden properties (new since clang-600.0.51, shipping with Xcode 6, thanks Marc Schlüpmann)
  when you override a property of a superclass, you must explicitly synthesize it

It's worth noting that synthesizing a property automatically synthesize the backing ivar, so if the property synthesis is missing, the ivar will be missing too, unless explicitly declared.

Except for the last three cases, the general philosophy is that whenever you manually specify all the information about a property (by implementing all the accessor methods or using @dynamic) the compiler will assume you want full control over the property and it will disable the autosynthesis on it.

Apart from the cases that are listed above, the only other use of an explicit @synthesize would be to specify a different ivar name. However conventions are important, so my advice is to always use the default naming.

Is @synthesize required for readwrite property?

@synthesize isn't required for anything anymore as long as you are using a modern LLVM compiler (the default for over 1 year now).

readwrite is the default so both properties are read/write. There is NO reason for the @synthesize line in the posted code.

The only exception to this is if you explicitly provide both the "setter" and "getter" for a readwrite property. Then the ivar is not automatically generated. For a readonly property the ivar isn't generated if you supply an explicit "getter".

iOS Automatic @Synthesize Without Creating an Ivar