error: writable atomic property cannot pair a synthesized setter/getter with a user defined setter/getter
I had the same problem and after doing a bit of research, here is my conclusion about this issue:
The compiler warns you about a @property
that you declared as atomic (i.e. by omitting the nonatomic
keyword), yet you provide an incomplete implementation of how to synchronize access to that property.
To make that warning disappear:
If you declare a @property
to be atomic then do one of the following:
- use
@dynamic
or; - use
@synthesize
and keep the synthesized setter and getter or; - provide a manual implementation of both the setter and the getter (without using one of the above directives).
If you declare the @property
with (nonatomic)
then you can mix manual and synthesized implementations of getters and setters.
Update: A Note on Property Auto-Synthesis
As of LLVM 4.0, CLang provides auto-synthesis for declared properties that are not @dynamic
. By default, even if you leave out the @synthesize
, the compiler will provide getter and setter methods for you. However, the rule for atomic properties is still the same: Either let the compiler provide both the getter and the setter, OR implement them both yourself!
You need to implement the getter also. Example:
// Interface:
@property (retain) NSObject * someProperty;
// Implementation:
- (void)setSomeProperty:(NSObject *)newValue
{
@synchronized (self)
{
// ...
}
}
- (NSObject *)someProperty
{
NSObject *ret = nil;
@synchronized (self)
{
ret = [[someProperty retain] autorelease];
}
return ret;
}
This question, among the other top hits you get from searching for "objective C custom property", are not updated with information about "setter =" or "getter =".
So, to supply more information on this question:
You can supply the @property call with your own method by writing
@property(setter = MySetterMethod:, getter = MyGetterMethod)
Notice the colon for the supplied setter method.
Reference Apple documentation
EDIT: I'm not quite sure how the new changes to Objective-C's properties (they are much more intelligent now) change the answers to this question. Perhaps it should all be marked as out of date.