In 2010 I used synchronous NSURLConnection‘s, completely blocking the UI (time pressure). In early 2010, I was working on a pre-existing app the did use asynchronous connections, but would block the Back button of a UIViewController until all completed. This was something the product managers really wanted fixed.
My solution used concurrent NSOperations (of which I’d had some prior experience). Using the “cancel” feature of operations, it was possible to stop all background operations when the user clicked the Back button and cleanup. It turns out there are many “corner” cases in the design—for instance, the user cancels before a queued operation has started running. Since the app also showed a spinner when the operations were running, the feature had to let the controller discover how many operations remained, in particular if all operations were complete.
Thus, in late winter, 2011, I had coded this feature into a UIViewController subclass, it was working pretty well, and I took what I’d learned and created an open source testbed for concurrent NSOperations on github, Concurrent_NSOperations, supporting both Mac and iOS targets.
This project allowed me to really flesh out the logic – the UI lets you choose the sequence of events (e.g., cancel before operations starts), and it let me catch and deal with many edge cases.