Concurrency in Swift: Threads, Goroutines, and async/await — How Not to Go Crazy

Introduction: Why doesn't your iPhone freeze while you scroll through your feed?

Have you ever wondered why modern iOS apps don't lag, even when they are simultaneously loading dozens of images, processing taps, and writing data to the database? The answer is simple — concurrency. In the world of Swift (and beyond), this is one of the hottest topics. And if you write in Swift, but still get confused by threads, goroutines, and the trendy async/await — welcome to the club. Today we'll break everything down so your code flies, not crawls.

In this article, we won't just list dry definitions. We'll look at real examples, compare approaches, and answer the main question: what to choose for your project — the good old GCD or the new Swift Concurrency?

Threads: The Foundation Everything Rests On

Let's start with the basics. A thread is the smallest unit of processing that an operating system can execute. Imagine a conveyor belt: one thread is one line along which tasks move. If you have a single-core processor, threads will execute one after another, but switching very quickly, creating the illusion of parallelism. On multi-core processors, threads can actually execute in parallel.

In Swift, for a long time, the main tool for working with threads was Grand Central Dispatch (GCD). You would simply create a queue and dispatch a closure to it:

DispatchQueue.global(qos: .background).async {\n    // Heavy work in the background\n    let result = heavyComputation()\n    DispatchQueue.main.async {\n        // Update UI on the main thread\n        self.label.text = result\n    }\n}

Simple, right? But GCD has its nuances:

\n
• You are responsible for returning to the main thread (easy to forget and get a crash).
\n
• No built-in support for task cancellation (you have to write flags manually).
\n
• Difficult to handle chains of dependent operations without nesting closures (the so-called "callback hell").
\n

Nevertheless, GCD is still alive and used in legacy projects. But modern Swift offers something much more elegant.

Goroutines in Swift? No, This Isn't Go

When people talk about goroutines, they usually think of Go. Swift doesn't have a direct analog of goroutines, but it has lightweight tasks that behave very similarly. They are not tied to a specific thread — the system itself decides which thread to execute a task on and can switch them between threads without creating new ones for each call.

Unlike threads, which "weigh" about 8 KB of stack each, Swift Concurrency tasks weigh practically nothing. You can launch thousands of tasks without the risk of overflowing memory. This is the very "concurrency without pain".

See how it looks:

Task {\n    let image = await downloadImage(from: url)\n    await MainActor.run {\n        self.imageView.image = image\n    }\n}

Notice? No DispatchQueue.main.async. Just await MainActor.run. Clean, clear, safe.

async/await: The Revolution That Happened

With the release of Swift 5.5, built-in support for async/await arrived. This is not just syntactic sugar — it's a paradigm shift. Now you can write asynchronous code as if it were synchronous, but without blocking the thread.

Declaring an async function is simple:

func fetchUserData() async throws -> User {\n    let url = URL(string: "https://api.example.com/user")!\n    let (data, _) = try await URLSession.shared.data(from: url)\n    return try JSONDecoder().decode(User.self, from: data)\n}

And calling it is even simpler:

Task {\n    do {\n        let user = try await fetchUserData()\n        print("User nam