> Don't iOS blocks natively perform tasks asynchronously?

The blocks themselves don't, no, they're just anonymous functions.

I'd hope NSOperationQueue[0] and maybe GCD composes most of what they mean by "use background threads".

And as sandyarmstrong notes, using things like operation queues will still impact your performances more than separate threads, as the main thread's runloop will still have to go through them, stuff like that.

[0] Which can take a block if an NSOperation is too much overhead for the work, see addOperationWithBlock:

Running a block async on the main thread can still hurt UI performance. Having worked on an app that deals with a lot of image downloading and processing, we needed to use a different runloop for downloading, and background operations to do image resizing and caching.

Between blocks and NSOperationQueue this all feels pretty natural in iOS development. You're not explicitly managing thread creation, etc.

pretty much every iOS app uses multi-threading (if they don't they should). GDC makes it pretty easy to implement, its defiantly not over-engineering. I highly recommend any new iOS programer to learn GDC when building their first app.

No unless you specify so. Block can be ran on both background and main thread.