Introduction

NSOperation and NSOperationQueue help structure concurrent work, but they do not change the main rule of Apple UI programming: UI updates belong on the main thread. The queue you choose determines where the operation runs, and that is what decides whether the work happens on the main thread or a background thread.

The most important distinction is simple: OperationQueue.main runs operations on the main thread, while a custom OperationQueue schedules them on background threads managed by the system.

Main Queue Versus Background Queue

If you add an operation to the main queue, it executes on the main thread:

OperationQueue.main.addOperation {
    print(Thread.isMainThread)
}

If you add it to a custom queue, it usually runs on a background thread:

1let queue = OperationQueue()
2queue.addOperation {
3    print(Thread.isMainThread)
4}

That is the key behavior. NSOperation itself is just the unit of work. NSOperationQueue decides how and where that work is scheduled.

A Background Operation Can Return To The Main Thread

A common pattern is to do expensive work on a background queue and then hop back to the main queue for UI updates:

1let backgroundQueue = OperationQueue()
2
3backgroundQueue.addOperation {
4    let result = "finished"
5
6    OperationQueue.main.addOperation {
7        print(result)
8    }
9}

This keeps expensive work off the UI thread while still updating UI state safely afterward.

Do Not Assume One Fixed Thread Per Operation

A background OperationQueue does not mean "my operation owns one permanent thread." The system manages threads under the hood. The important contract is not a specific thread identity, but whether the queue is the main queue or a background queue and how many operations it allows concurrently.

That is why queue semantics matter more than trying to memorize exact thread behavior.

Why NSOperationQueue Is Useful

Compared with low-level threading, operations give you higher-level coordination features:

• dependencies between operations
• cancellation
• readiness and completion state
• control over maximum concurrency

Those features are often more valuable than raw thread creation because they make concurrent code easier to reason about.

Dependencies And Ordering Are Separate From Threads

One reason operations stay useful is that you can express ordering with dependencies instead of hard-coding thread coordination. An operation may still run in the background, but you can require it to wait until another operation finishes without manually blocking the main thread.

Main Queue Does Not Mean Async UI Work Is Free

Adding work to the main queue can still be asynchronous relative to the calling code, but it is not free from UI cost. If the work itself is heavy, it still runs on the main thread and will still block rendering and interaction until it finishes.

Cancellation Does Not Mean Preemption

Calling cancel on an operation marks its state, but your operation code still needs to check for cancellation and respond appropriately if the work is custom or long-running. Cancellation is a coordination signal, not an automatic interruption guarantee.

Common Pitfalls

• Updating UIKit or AppKit state from a background operation.
• Assuming an operation runs on the main thread unless told otherwise.
• Assuming a background queue means one dedicated thread per task.
• Doing expensive work on OperationQueue.main and freezing the UI.
• Ignoring dependencies and cancellation even though operations support them directly.

Summary

• 'OperationQueue.main runs operations on the main thread.'
• Custom operation queues run work on background threads managed by the system.
• Use background queues for expensive work and the main queue for UI updates.
• Focus on queue semantics, not on one-thread-per-operation assumptions.
• 'NSOperation is valuable because it adds structure, dependencies, and cancellation on top of concurrency.'