Introduction

Objective-C properties are atomic by default, which often leads developers to assume they are broadly thread-safe. They are not. An atomic property only guarantees that a single generated getter or setter completes without returning a torn value. It does not make larger read-modify-write sequences safe, and it does introduce some overhead.

What atomic Actually Guarantees

When a property is declared atomic, the synthesized accessor methods coordinate access so one thread does not observe a partially written pointer or object reference. In other words, a getter returns a valid object pointer, and a setter stores the new pointer in one protected step.

@interface CounterStore : NSObject
@property (atomic, strong) NSNumber *count;
@end

This helps with basic accessor integrity. If one thread is assigning a new object while another thread reads the property, the reader should still get a valid object reference rather than a corrupted value.

What atomic Does Not Solve

Atomic accessors do not protect compound logic. If your code reads a value, computes a new value, and writes it back, those are still multiple steps.

NSNumber *current = self.count;
NSInteger nextValue = current.integerValue + 1;
self.count = @(nextValue);

Even with an atomic property, two threads can read the same old value and both write back the same incremented result. That means updates can still be lost. If the operation must be truly thread-safe, you need a higher-level synchronization mechanism such as a serial queue, @synchronized, or another locking strategy.

Performance Side Effects

The main side effect of atomic is extra cost on every property access. The exact implementation details are not something you usually manage directly, but the runtime has to do more work than a nonatomic accessor. In UI-heavy code, where properties are accessed frequently on the main thread, that overhead often brings no benefit because there is no real concurrent access to protect.

That is why iOS and macOS application code commonly uses nonatomic unless there is a specific reason to prefer atomic behavior.

Another subtle point is that atomic behavior applies to the synthesized accessor methods. If code bypasses the property and touches the instance variable directly, that access does not get the same protection.

Mutable Objects Are a Separate Problem

Another common misunderstanding is that atomic protects the contents of a mutable object. It does not. It only protects the property access itself.

1@interface Store : NSObject
2@property (atomic, strong) NSMutableArray *items;
3@end
4
5[self.items addObject:@"A"];

The property getter may return the array safely, but the array's internal mutations are a different concern. If several threads modify the same mutable collection, you still need synchronization around the collection operations.

When to Choose nonatomic

Use nonatomic when the property is only accessed from one thread or when you already manage synchronization at a higher level.

@interface ProfileViewModel : NSObject
@property (nonatomic, copy) NSString *displayName;
@end

This is the normal choice for most app-level model and view code. It is simpler, faster, and usually matches how UIKit and AppKit code is actually used.

When atomic Can Still Make Sense

Atomic properties are not useless. They can be reasonable when a property is occasionally read and written from different threads and you only need accessor-level safety. That is a narrower requirement than full thread safety, but it does exist.

The important part is to be precise about what problem you are solving. If you need protected object ownership across threads, atomic may help. If you need consistent multi-step state updates, it is not enough.

Common Pitfalls

• Assuming atomic makes a class fully thread-safe. It does not.
• Using an atomic property for mutable collections and expecting internal mutations to be protected.
• Paying accessor overhead in main-thread UI code where concurrent access is not part of the design.
• Forgetting that compound operations still need explicit synchronization.

Summary

• 'atomic only protects individual getter and setter operations.'
• It helps prevent torn reads or writes of the property value itself.
• It does not make multi-step logic or mutable object usage automatically safe.
• 'nonatomic is usually the better default for normal application code.'
• Choose atomic only when accessor-level synchronization is actually the problem you need to solve.