Does iOS OperationQueue have the same features of Android WorkManager (persistent, multiple tries, ability to see queue and status, network)?

Question

I am looking to use a mechanism, like Android's WorkManager, in iOS. I want to submit work to be done, have it run when the network is connected. I also need to see the work in the queue, try a certain number of times, see what the errors were encountered and cancel/re-queue the work.

I saw this post on queueing work in iOS for when the network becomes available, which recommends OperationQueue. This post also mentions OperationQueue. I have also seen this post on features within URLSession to run in the background which persist.

After the work is done, I need it to update an entity in CoreData as well. All of this I do currently in Android with WorkManager. I can see the full queue, the ones that failed, control the things which need to be in place for them to run (network), restart them or remove them.

Answer 1

Operation queues just manage dependencies between individual operations. Unfortunately, this is cumbersome when the operations wrap work that is, itself, asynchronous, requiring clumsy manual implementation KVC and KVO. Because of all of this, nowadays we would reach for Swift concurrency, which handles all of this far more elegantly. Operation queues were an elegant, though complicated, solution, but are arguably a bit of an anachronism nowadays. For a comparison of Swift concurrency, operation queues, and Combine, see How To Download Multiple Files Sequentially using URLSession downloadTask in Swift.

That having been said, if you want network requests to persist even after the user has left the app, none of those patterns will quite work. For this, we would often reach for a background URLSessionConfiguration. This is ideal for network requests that may take more than a few seconds (e.g., downloading/uploading a huge asset, such as a video) or requests that should be submitted when network connectivity is re-established. The Downloading files in the background outlines many of the idiosyncratic details. And this pattern works for uploads, too (though there are some specific additional requirements for uploads, specifically that one must upload from a file rather than using the httpBody).

In short, I would suggest focusing on background URLSessionConfiguration, where an out-of-process daemon will manage the outstanding network requests for you.

Regarding the ability to fetch the list of pending tasks when the user relaunches the app, getTasksWithCompletionHandler(_:) returns a list of pending tasks.