Is it as straightforward as non-concurrent code? No, obviously it isn't. Is it so mind-bendingly difficult that we need to be paralyzed by fear at the mere mention of concurrency? No, it isn't that either.

There are things you can do to make concurrency easier. Dispatch queues for one eliminate a lot of bugs. Being thoughtful about when and how we use concurrency is another. Race condition bugs are sometimes difficult to track down and cure, but if you understand the basic concepts around concurrency and controls around that they're generally fairly easy to avoid.

The biggest problem I've run into with people is they don't even understand what mutexes, semaphores, condition variables, or atomic variables are or when you'd use each. People don't know what joining a thread is. I ran into a bug at a previous job where they were spawning and destroying threads very quickly (which is a problem, but not their main problem) and instead of using a join to block until a thread's completion they were using sleep(1). Switching to a join sped up their code immensely and improved a data processing operation that previously took months to now taking days.

tl;dr people need to a) read up on how to do concurrency and b) be more thoughtful about the code they're writing when doing it. It's not so scary we should just avoid it altogether, especially when the user experience can be greatly improved by using it. Concurrency is another tool in the toolbag, even if it's a chainsaw without a cover.