OperationQueue.main vs DispatchQueue.main OperationQueue.main vs DispatchQueue.main swift swift

OperationQueue.main vs DispatchQueue.main


For details on the differences between the two types of queue, see Lion's answer.

Both approaches will work. However, NSOperation is mostly needed when more advanced scheduling (including dependencies, canceling, etc.) is required. So in this case, a simple

DispatchQueue.main.async { /* do work */ }

will be just fine. That would be equivalent to

dispatch_async(dispatch_get_main_queue(), ^{ /* do work */ });

in Objective-C, which is also how I would do it in that language.


When to Use NSOperation

The NSOperation API is great for encapsulating well-defined blocks of functionality. You could, for example, use an NSOperation subclass to encapsulate the login sequence of an application.

Dependency management is the icing on the cake. An operation can have dependencies to other operations and that is a powerful feature Grand Central Dispatch lacks. If you need to perform several tasks in a specific order, then operations are a good solution.

You can go overboard with operations if you are creating dozens of operations in a short timeframe. This can lead to performance problems due to the overhead inherent to the NSOperation API.

When to Use Grand Central Dispatch

Grand Central Dispatch is ideal if you just need to dispatch a block of code to a serial or concurrent queue.

If you don’t want to go through the hassle of creating an NSOperation subclass for a trivial task, then Grand Central Dispatch is a great alternative. Another benefit of Grand Central Dispatch is that you can keep related code together. Take a look at the following example.

let dataTask = session.dataTaskWithRequest(request, completionHandler: { (data, response, error) -> Void in// Process Response...dispatch_async(dispatch_get_main_queue(), { () -> Void in    // Update User Interface    ...})})

In the completion handler of the data task, we process the response and update the user interface by dispatching a closure (or block) to the main queue. This is necessary because we don’t know which thread the completion handler is executed on and it most likely is a background thread.

Quoted verbatim from this source


DispatchQueue manages the execution of work items. Each work item submitted to a queue is processed on a pool of threads managed by the system.

Reference : Apple Doc

The NSOperationQueue class regulates the execution of a set of Operation objects. After being added to a queue, an operation remains in that queue until it is explicitly canceled or finishes executing its task. Operations within the queue (but not yet executing) are themselves organized according to priority levels and inter-operation object dependencies and are executed accordingly. An application may create multiple operation queues and submit operations to any of them.

Reference : Apple Doc

So, you should prefer DispatchQueue.main.async when you want to perform something on main thread from completion block of any network call. Especially when it is related to UI Updates! And If your task is complex, I mean if you require further operation on running task then you can go with OperationQueue.main.addOperation otherwise DispatchQueue.main.async will give more optimal performance comparatively!