As you have likely figured out by now, your rationale for wanting to use operations is based upon some faulty assumptions. You simply do not need operations if all you want is to support concurrent network requests. That is an inherent feature of URLSession
, namely that all network requests are asynchronous. You actually have to contort yourself to not have network requests run concurrently (and most attempts to do so that I've seen on this forum are ill-advised; noobs seem to love semaphores; lol).
That having been said, there might be reasons why you would want to use operation queue, e.g.:
If you wanted concurrency, but you wanted to control the degree of concurrency (e.g., not more than four concurrent requests at a time).
If you wanted dependencies between operations.
You want to cancel all the operations on a queue.
But the proper use of operation queues for an asynchronous task, such as a network request, requires some care. Your attempt outlined in your question is creating an operation for the initiation of a network request, but it does not wait for the response. The operation is finishing immediately. That defeats the purpose of operation queues.
You would want to create an Operation
subclass that manually managed the KVO associated with the various isExecuting
, isFinished
, etc., properties. See the Operation
documentation. Or see Trying to Understand Asynchronous Operation Subclass for a general discussion about how to create asynchronous Operation
subclasses. Or see WWDC 2015 Advanced NSOperations (which uses Objective-C, but the concepts associated with asynchronous operations is discussed; but this video is outdated and they actually pulled their code samples because they had issues in their (IMHO) over-engineered solution). For a practical example of operation queues with network requests, see How To Download Multiple Files Sequentially using NSURLSession downloadTask in Swift for example with download tasks. The same pattern can be used for data tasks, too.
All of that having been said, using operations is a bit of an anachronism at this point. If supporting iOS 13 and later, I use async-await and Swift concurrency. Even Combine offers better patterns for managing dependencies of asynchronous tasks than operation queues. Do what you want, but, IMHO, it might not be a good investment of time to learn the intricacies of proper asynchronous Operation
implementations nowadays, when there are newer patterns that are so much better.