I see this all the time when I'm reviewing PRs from developers who are comfortable with Grand Central Dispatch (GCD) but haven't spent much time with OperationQueue. They'll tell me, "Why would I use OperationQueue? It's just a wrapper around DispatchQueue, so it's slower and adds unnecessary overhead."

The myth that OperationQueue is just "bloated GCD"

On a purely technical level, yes, OperationQueue is built on top of GCD. If you are just trying to move a heavy calculation off the main thread to keep your UI responsive, using DispatchQueue.global().async { ... } is faster to write and marginally more performant. But the "overhead" people complain about isn't bloat—it's state.

Here is where the misconception falls apart: DispatchQueue is "fire and forget." Once you dispatch a block of code, you have very little control over it. You can't easily ask it if it's finished, you can't easily cancel it once it's started, and you certainly can't tell it to wait for three other unrelated tasks to finish before it begins.

If you try to implement a complex sequence of tasks—like downloading a high-res image, applying a blur filter to it, and then saving it to a database—using only DispatchQueue, you'll end up with "callback hell" or a mess of DispatchGroup calls that are a nightmare to debug. I've spent way too many hours hunting bugs in GCD code that tried to do too much orchestration.

Orchestration over raw execution

The real power of OperationQueue is that it treats a task as an object (an Operation) rather than a closure. Because it's an object, that task has a lifecycle. It can be pending, executing, finished, or cancelled.

Think about a photo gallery app. As the user scrolls rapidly through a list, you're triggering image downloads for cells. If a cell scrolls off-screen, you don't want to keep downloading that image; it's a waste of data and CPU. With DispatchQueue, that task is already gone—you can't stop it. With OperationQueue, you just call operation.cancel().

// With OperationQueue, we can manage dependencies
let downloadOp = DownloadOperation(url: imageURL)
let filterOp = FilterOperation()
let saveOp = SaveOperation()

// The magic: filterOp won't start until downloadOp succeeds
filterOp.addDependency(downloadOp)
saveOp.addDependency(filterOp)

let queue = OperationQueue()
queue.addOperations([downloadOp, filterOp, saveOp], waitUntilFinished: false)

// And if the user leaves the screen? 
// I can kill the whole chain instantly.
queue.cancelAllOperations()

I usually tell my mentees to follow this rule of thumb: If you just need to jump off the main thread for a second, stick with DispatchQueue. But the moment you find yourself saying "I need this to happen after that," or "I might need to stop this halfway through," you've outgrown GCD. You need a queue that understands the state of the work it's doing.

• DispatchQueue: Lean, fast, great for simple background tasks. Hard to cancel, no built-in dependency management.
• OperationQueue: Object-oriented, allows for dependencies, supports cancellation, and lets you limit the number of concurrent operations (via maxConcurrentOperationCount).

📋 Practical Task

Building a Cancelable Image Processing Pipeline

You are building a feature where a user can upload multiple photos, and each photo must be resized and then watermarked before being uploaded to a server. To prevent the app from freezing or crashing due to memory pressure, you cannot run all these tasks at once.

Your Task: Implement a processing manager using OperationQueue that meets these requirements:

1. Create a custom Operation subclass called ImageProcessOperation that simulates a heavy task (use Thread.sleep(forTimeInterval:) to simulate work).
2. Initialize an OperationQueue and set its maxConcurrentOperationCount to 2, ensuring the device isn't overwhelmed.
3. Create a sequence of three operations: ResizeOperation, WatermarkOperation, and UploadOperation.
4. Set up dependencies so that the watermark only happens after resizing, and the upload only happens after watermarking.
5. Add a mechanism to cancel all pending operations if a "Cancel All" trigger is activated.

Verify your implementation by printing logs to the console showing the order of execution and confirming that cancelled operations do not complete their "work."