Introduction

Dispatch queues, threads, and NSRunLoop are related, but they are not interchangeable concepts. A dispatch queue is a scheduling mechanism. A thread is an execution resource. A run loop is an event-processing loop attached to a thread. Many Apple-platform concurrency misunderstandings happen because these three ideas get collapsed into one mental model.

A Dispatch Queue Is Not a Thread

Grand Central Dispatch schedules blocks of work onto threads managed by the system. When you call DispatchQueue.global().async, you are saying "please run this work on an appropriate background thread when resources are available." You are not creating or owning a specific thread.

DispatchQueue.global(qos: .userInitiated).async {
    print("Running on thread: \(Thread.current)")
}

That block runs on some thread, but the queue itself is not the thread.

Important consequences:

• one queue can execute work on different threads over time
• one thread can execute work from different queues over time
• dispatching asynchronously does not guarantee a brand-new thread

The Main Queue and the Main Thread

The main queue is the special exception most developers learn first. It targets the main thread, and UI work must happen there.

DispatchQueue.main.async {
    self.view.backgroundColor = .systemBlue
}

Here, queue and thread are tightly associated in practice, which is why people often overgeneralize that relationship to all queues.

What NSRunLoop Actually Is

A run loop keeps a thread alive to process input sources, timers, and scheduled events. The main thread has a run loop because UIKit and AppKit rely on one to process user input, redraw requests, timers, and other event-driven work.

Background threads do not automatically need or use a run loop. Many GCD tasks run on worker threads with no run loop involvement that you need to think about.

So the right mental model is:

• queue decides when work should be scheduled
• thread is where instructions execute
• run loop keeps certain threads responsive to event sources

When Run Loops Matter

You care about a run loop when using APIs that depend on one, such as:

• timers scheduled on a specific thread
• input sources tied to that thread
• some legacy networking or stream APIs
• UI event processing on the main thread

If you are just using GCD for background computation or I/O callbacks, you often do not interact with NSRunLoop directly at all.

A Useful Comparison

Think of a queue as a to-do list, a thread as the worker, and the run loop as the mechanism that keeps a worker awake to listen for more events.

That analogy is not perfect, but it prevents two common mistakes:

• assuming every queue owns a dedicated thread
• assuming every thread naturally has a run loop you should care about

Common Pitfalls

• Treating dispatch queues and threads as if they were the same abstraction.
• Assuming async means a new thread is created every time.
• Expecting background GCD work to have a run loop just because the main thread does.
• Forgetting that the main queue is special because it targets the main thread and UI event system.
• Reaching for raw threads when a dispatch queue already expresses the scheduling intent clearly.

Summary

• A dispatch queue schedules work; it is not a thread.
• A thread is the execution context that actually runs instructions.
• A run loop processes timers and input events on a thread that needs that behavior.
• The main queue is tied to the main thread, but most other queues are not tied to one thread forever.
• Clearer mental separation between these three concepts makes Apple-platform concurrency much easier to reason about.