More like spaghetti code, then. dispatch_async() with NSURLConnection's synchronous method is way cleaner and faster to build an app with than NSURLConnectDelegate callbacks and holding onto the reference of multiple NSURLConnection instances.

It's possible to organize your code using asynch methods, but considering Apple's move toward block-based APIs, that's what I choose to use when architecting the apps I write.

Apple's block-based APIs aren't intended to replace asynchronous APIs. In fact, Apple's block-based APIs ARE asynchronous APIs. Half of the intent of GCD is to provide a dynamic-thread-queue asynchronous interface to non-blocking I/O APIs via kqueue and friends.

GCD aside, there are a ton of reasons not to use synchronous networking, from the resource costs (you're paying for a thread stack per request) to the inability to cancel the synchronous request.

One of Apple's engineers (Quinn) wrote up a whole post on the dev forums about why you should not use synchronous networking. It's a "sticky" post at the top of the iOS->Core OS forum:

https://devforums.apple.com/thread/9606?tstart=0

Lastly, I think your position on spaghetti code is misguided. A block-based wrapper on NSURLConnection will be just as simple as dispatch_async().

It's also less portable, pluggable, testable...