The Dangers of Using Nonatomic Properties
For some reason, the decision was taken to make properties default to “atomic”, but no attempt was made to convert any pre-existing getter/setter implementations, and no attempt was made to verify that any new custom accessors provided atomicity. The whole thing was broken right from the start.
Although nothing syntactic has ever changed, common usage has changed over the years, to (informally) regard the default (omission of attribute) and explicit “atomic” as different things, in terms of API contract. The usage has come to be that only properties explicitly marked “atomic” can be reasonably assumed to be making an API contract, and that properties without the attribute make no API contract (even if they happen to be atomic as an implementation detail).
I can’t speak to that decision: it pre-dates me. At a guess, probably over-enthusiasm for the idea of eliminating low-level failures due to races, buoyed by the era’s general optimism about the ability of future machines to hide the performance cost. Atomic properties may not provide a (typically) semantically meaningful level of atomicity, but they do prevent races on the property from immediately leading to crashes.
Another influence was Objective-C garbage collection. GC was assumed to be The Future, and atomic properties are cheap when you have GC.
Update (2017-05-02): The title comes from this blog post. I actually prefer nonatomic properties myself. Atomic properties can be slow and give a false sense of security.
