Why are Cocoa's IBOutlet properties atomic by default, and Cocoa Touch's aren't?

Question

If you drag a new outlet from Interface Builder to an interface (header) file, Xcode 4.6 will automatically create a property for you...

On iOS (Cocoa Touch) it will look like this:

@property (weak, nonatomic) SomeClass *someProperty; //nonatomic accessors 

Whereas on OS X (Cocoa) it will look like this:

@property (weak) SomeClass *someProperty; //atomic accessors (implicitly) 

Why?

EDIT: I am not asking about what atomic does or doesn't do, I'm well aware of the synchronize directive and the underlying mutex (or lock or whatever) that guarantees atomicity of the setter and getter. I know that on iOS, accessors are nonatomic because UIKit is not thread safe, and so there is nothing to be gained by making them atomic, it's just a waste of processor time and battery life. I am talking about the default case here, programmers who know what they are doing will know when they need to make their accessors atomic.

So I'm asking why they are atomic by default on OS X. I was under the impression that Appkit was not thread safe either. And having atomic accessors doesn't guarantee thread safety, I'd even go as far as to say it goes the opposite way in that it can give the illusion of thread safety to novice programmers and make bug tracking harder in concurrent apps by deferring crashes to a later time and in so doing making them harder to trace. And just because desktop computers are relatively powerful doesn't mean resources should be wasted (note I am not talking about premature optimization here), and since it stands to reason that Apple engineers are reasonable programmers, there must be a good reason why they have decided to make the properties synthesize atomic accessors by default.

Answer 1

In this context the atomic specifier tells the compiler that the setter and accessor should be synthesised so as to be safe to call from multiple threads. This adds a small overhead by requiring the methods to take out a lock before a properties value can be written or read.

Since user interface elements of both UIKit and Cocoa are only ever intended to be accessed from the main thread the extra lock is unnecessary. The overhead of making a property atomic is pretty minimal, but in the more constrained environment of iOS every little ounce of speed is valuable.. hence why iOS defaults to using nonatomic properties for IB Outlets.

Edited in response to your expanded question: My feeling is that the cost of using atomic properties is worth the overhead on the Mac. Theres an argument that using atomic properties masks a collection of bugs and is therefore a bad thing. I'd argue that from a users perspective Apple should set the defaults so that even badly coded applications crash less. It puts the onus on advanced programers to know when it's safe to use nonatomic properties in exchange for a performance advantage.

Without hearing from someone on the team at the time we can only speculate about their thought process but I'm sure it was a considered decission.

Answer 2

Simple as hell: atomic causes overhead (negligible one on OSX) with its implicit mutex mechanisms.

iOS (as an embedded system on a ARM chip) can't afford this overhead, hence IBOutlets defaulting to nonatomic.

In one word: Performance.

As to why they default to atomic on OSX, thread-safety on properties is a nice thing to have in a massively multi-threaded, multi-application environment like OSX (especially compared to iOS, apps are more likely to interact with each other on OSX than on iOS).

And as said before, the overhead is really negligible on OSX, thus they defaulted it like this.