Introduction

In Objective-C, nonatomic means the property's generated getter and setter are not made atomic by the runtime. That usually makes access faster, but it also means the property declaration is not providing accessor-level synchronization.

This is the normal choice for most app code. nonatomic does not automatically make a program unsafe; it just means thread safety must come from the surrounding design rather than from the property attribute itself.

What nonatomic Looks Like

A typical declaration is:

@property (nonatomic, copy) NSString *titleText;

With nonatomic, the compiler generates an unsynchronized accessor pair. That is a very common choice for UI state, model properties, and other values that are usually touched on one thread.

Compare It with atomic

If you omit nonatomic, Objective-C properties are atomic by default. atomic does not make the whole object thread-safe, but it does ask the generated accessor methods to behave more defensively under concurrent access.

So the practical distinction is:

• 'atomic: accessor-level synchronization, more overhead'
• 'nonatomic: no accessor-level synchronization, less overhead'

That is why everyday iOS and macOS application code often prefers nonatomic.

Why nonatomic Is Common in App Code

Most UIKit and AppKit code is expected to run on the main thread. If a property belongs to a view controller, label, button, or view model that is updated only there, atomic accessor protection adds cost without solving a real problem.

For example:

@property (nonatomic, strong) UILabel *titleLabel;
@property (nonatomic, copy) NSArray *items;

These are normal declarations because the intended threading model already makes concurrent access unlikely or invalid.

It is also important to separate property atomicity from memory-management semantics. strong, weak, copy, and assign still behave the same way whether the property is atomic or nonatomic.

What nonatomic Does Not Mean

nonatomic does not mean:

• ARC stops retaining or copying correctly
• the property is broken
• reads and writes become random
• you cannot use the property in a multithreaded program

It only means the property itself is not doing atomic accessor work for you.

Thread Safety Still Needs a Bigger Design

Even atomic properties do not make compound logic safe:

self.counter = self.counter + 1;

That is still a read-modify-write sequence, not one indivisible operation. So if several threads must coordinate access, the real solution is a queue, lock, ownership rule, or other synchronization strategy.

Changing a property from atomic to nonatomic or back does not replace a concurrency design.

The same applies if code bypasses the property and accesses the ivar directly. Property attributes affect generated accessor behavior, not every possible way the object can be touched.

When nonatomic Is the Right Default

Use nonatomic when:

• the property is effectively main-thread-only
• access is already serialized elsewhere
• you care more about ordinary property performance than accessor synchronization

That covers a large fraction of normal Objective-C properties.

Common Pitfalls

• Assuming nonatomic automatically makes a class unsafe.
• Assuming atomic would make a whole object thread-safe.
• Using atomic on UI properties even though all access is already on the main thread.
• Trying to fix synchronization bugs by changing the property attribute alone.
• Forgetting that property attributes affect generated accessors, not every possible ivar access path.

Summary

• 'nonatomic means the property's generated getter and setter are not atomic.'
• It is usually faster than atomic and is common in normal Objective-C app code.
• It does not provide thread safety by itself.
• Most UI properties are nonatomic because they are expected to stay on one thread.
• If multiple threads must coordinate access, solve that explicitly outside the property attribute.