Should @synthesize be used still?

Question

I\'m just wondering if @synthesize should still be used even though Xcode does it automatically for properties, simply because it\'s been done that way for so long? Or does

Answer 1

There really is no overall correct answer for this. Other than the specified technical reasons given by the other answers (such as tying an alternate ivar name to a property), I feel it is most important to keep consistent with your code. If you are contributing with older libraries that use @synthesize all over the place, you might want to stick with it in the name of consistency. Otherwise, if you are starting anew and shooting for the less verbose approach, stick with omitting @synthesize as much as possible. I personally like less verbose code, but I value code consistency somewhat more, especially when weeding through thousands of lines of code.

Answer 2

I personally no longer use synthesize for new development only unless required (see lnafziger's comment below). The reason is because I currently develop for iOS 6, which requires a new version of Xcode, which has the capabilities of auto-including the @synthesize during compile time. If I were to do this with old code, there may still be someone in my organization that is using an old version of Xcode (i.e version 4.2) where this would cause problems for them.

So depending on if you still need to be compatible with the older versions of Xcode, this answer will vary. But if you only need to work with new versions of Xcode, you should be fine not declaring @synthesize.

Answer 3

If you are ok with your ivar being synthesized with _propertyName you can safely get rid of the synthesize statements. If you want your ivar to be named something else, you need to include it like so

@synthesize propertyName = ________cool_ivar_name

Answer 4

To directly answer your question, I think, skipping @synthesize is not unprofessional. Assuming you don't requiring it for some reason (and I'll talk about that), I think it's more professional to write less and cleaner code. @synthesize is just noise.

There's a few cases where you might consider it:

1. You need compatibility with the old (32 bit OS X) runtime, or an older version of iOS (pre 4.0).

   Note: Though you might care about 32 bit OS X, I'm not even sure Apple would even accept an app that targets iOS prior to 4.0 now. Certainly, you're going to be really limit yourself.

2. Your product is a source library you want other developers to be able to use with older versions of Xcode.
3. You need to use an older version of Xcode (pre 4.4).
4. You've hit an edge case in the language where @synthesize is required. (There's at least one case of this, related to categories.) If you hit this, @synthesize that one variable and move on. Don't go back and @synthesize everything.

Note that if you turn on -Weverything you'll get compiler warnings about this. -Weverything includes everything, including some warnings that suggest changes I'd consider ill-advised. This is one of them. Find the appropriate warning switch to turn it back off (it's in the warning message) and do so. :)

See also:

• Objective-C Feature Availability Index