11 iOS GCD and Swift Concurrency Interview Questions and Answers

Short answer: A queue is a "list of tasks" abstraction, not a thread: GCD multiplexes queues over a shared thread pool. A serial queue runs tasks strictly one at a time in FIFO order; a concurrent one runs several in parallel. Main is the only queue with the contract "I execute on the main thread"; global queues are system concurrent queues, one per QoS class.

In depth:

1. Queue ≠ thread — a serial queue doesn't own a thread: its tasks may run on different pool threads, just never simultaneously.
2. QoS drives scheduling — QoS tells the system how much CPU and energy to grant: .userInteractive jumps the line, .background can wait.

⚠️ Common mistake: "creating a queue creates a thread." No: thousands of queues are served by a dozen pool threads. But blocking many threads with sync waits is the road to thread explosion.

Short answer: Deadlock and a crash. sync blocks the current thread until the block runs, but the block is waiting for its turn on main — a serial queue whose only thread we just blocked. Neither side ever proceeds.

In depth:

// already executing on the main thread:
DispatchQueue.main.sync {
    print("we never get here")
}
// 💥 EXC_BAD_INSTRUCTION — deadlock

1. Mechanics — sync means "enqueue the block and wait for it to finish." Main is serial: the next block starts only after the current one ends. But the current one (our code) is blocked waiting → mutual waiting forever.
2. From a background thread — legal — DispatchQueue.main.sync { ... } from a global queue is correct: the background thread blocks while main is free and runs the block. It's occasionally used to read UI state synchronously, though async is almost always the better fit.
3. Diagnostics over guessing — dispatchPrecondition(condition: .onQueue(.main)) asserts the queue explicitly, instead of a "sync just in case."

⚠️ Common mistake: a helper like "if not on main — sync onto main, else run inline" that one day gets called from code already inside a sync chain. The general rule: sync onto the serial queue you are currently on is always a deadlock; main is just the most common instance.

Short answer: 1 3 5 6 2 4 7. Two rules decide everything: sync runs the block immediately while blocking the current thread, and main.async merely enqueues the block — it can't start until the code currently running on main finishes.

In depth:

// running on the main thread
print("1")
DispatchQueue.main.async { print("2") }
DispatchQueue.global().sync {
    print("3")
    DispatchQueue.main.async { print("4") }
    print("5")
}
print("6")
DispatchQueue.main.async { print("7") }

1. 1 — a plain synchronous call.
2. main.async { 2 } — the block joins the main queue and waits: main is busy running the current code.
3. global().sync — main blocks and the block runs right away (usually on the main thread itself: GCD avoids a thread hop when it can). It prints 3, main.async { 4 } — again only enqueued, then 5.
4. 6 — execution continues after sync returns.
5. main.async { 7 } — a third block joins the main queue.
6. The current code finishes — main drains the backlog in FIFO order: 2, 4, 7.

⚠️ Common mistake: answering "2 right after 1." async onto the same queue never runs immediately, even if the queue looks "free": the block currently running on it must finish first.

Short answer: counter += 1 is a read, an increment, and a write: three steps with no atomicity. Threads read the same stale value and overwrite each other's writes — a classic data race. The fix is serializing access: a serial queue, a barrier, a lock, or an actor.

In depth:

var counter = 0
DispatchQueue.concurrentPerform(iterations: 4) { _ in
    for _ in 0..<100 { counter += 1 }   // read-modify-write — not atomic
}
print(counter)   // e.g. 317 — different on every run

Ways to fix it:

1. Serial queue — funnel all access through queue.sync { counter += 1 }.
2. Concurrent + barrier — parallel readers, exclusive writer:

@propertyWrapper final class Atomic<Value> {
    private let queue = DispatchQueue(label: "atomic", attributes: .concurrent)
    private var value: Value
    init(wrappedValue: Value) { value = wrappedValue }
    var wrappedValue: Value {
        get { queue.sync { value } }
        set { queue.async(flags: .barrier) { self.value = newValue } }
    }
}

3. NSLock / os_unfair_lock — minimal overhead.
4. Actor — the language-level answer: the compiler itself refuses access that bypasses isolation.

To catch races — Thread Sanitizer (scheme → Diagnostics → TSan).

⚠️ Common mistake: believing this @Atomic fixes counter += 1. That's a separate get and a separate set — another thread can slip in between. The whole read-modify-write operation must be atomic, not the property piecewise.

Short answer: DispatchGroup: call enter() before starting each operation, leave() in its completion, and collect the result via notify(queue:) without blocking. DispatchSemaphore(value: N) caps how many operations run at once. A blocking wait() on the main thread means a frozen UI or a deadlock.

In depth:

let group = DispatchGroup()
for url in urls {
    group.enter()
    load(url) { result in
        defer { group.leave() }   // leave guaranteed on every exit path
        store(result)
    }
}
group.notify(queue: .main) { updateUI() }   // does not block

// semaphore: at most 3 downloads at a time
let sem = DispatchSemaphore(value: 3)
for url in urls {
    worker.async {
        sem.wait()
        defer { sem.signal() }
        download(url)
    }
}

1. enter/leave symmetry — exactly one leave() per enter(); defer protects against an early return in the completion. An extra leave crashes; a missing one means notify never fires.
2. notify vs wait — notify schedules the block and returns immediately; wait() halts the current thread (tolerable on a background thread, preferably with a timeout).

⚠️ Common mistake: group.wait() or sem.wait() on the main thread "to wait for the network." If the completion is also delivered on main — deadlock; if not — the UI simply freezes for the whole wait. On main, notify only.

Short answer: OperationQueue is a layer on top of GCD that turns a task into an object: cancellation, dependencies, observable states, a concurrency limit. Reach for it when tasks need managing after launch; for fire-and-forget, GCD is enough.

In depth:

1. Cancellation is cooperative everywhere — even in an Operation, a long loop must periodically check isCancelled and bail out itself.
2. The classic follow-up — an asynchronous Operation (wrapping a network call) requires a manual state machine: override isAsynchronous and send the KVO notifications for isExecuting/isFinished yourself — otherwise the queue considers the operation finished right after main().

⚠️ Common mistake: comparing them on speed. OperationQueue runs on GCD internally; the question isn't "which is faster" but whether the task needs a lifecycle: cancellation, dependencies, observability.

Short answer: A task tree. Child tasks (async let, TaskGroup) inherit the parent's priority and cancellation and cannot outlive its scope — the compiler guarantees the function won't return while its children are alive. In GCD, the lifetime of work has no tie to the code that spawned it.

In depth:

func loadDashboard() async throws -> Dashboard {
    async let user = fetchUser()   // child task — starts in parallel
    async let feed = fetchFeed()
    return try await Dashboard(user: user, feed: feed)
}   // leaving the function while abandoning the children is impossible

try await withThrowingTaskGroup(of: Image.self) { group in
    for url in urls {
        group.addTask { try await download(url) }  // inherits priority and cancellation
    }
    for try await image in group { save(image) }
}

1. Cancellation cascades — cancel the parent and every child gets the flag. But cancellation is cooperative: nothing stops by itself, long-running code must check try Task.checkCancellation().
2. Errors flow up the tree — a failed child cancels its siblings, and the error surfaces at the parent's await.
3. The contrast — Task.detached and a GCD block live on their own: cancellation, priority, and waiting for completion are all wired up by hand.

⚠️ Common mistake: expecting cancellation to "kill" a task. Cancel merely sets isCancelled; a task that never checks the flag calmly runs to completion.

Short answer: Task {} inherits the actor context, priority, and task-local values of its creation site; Task.detached inherits nothing. Hence the trap: a Task {} inside @MainActor code runs on the MainActor — the "background" work actually blocks the UI. Detached is a rare tool for genuinely independent work.

In depth:

@MainActor final class ViewModel: ObservableObject {
    @Published var items: [Item] = []

    func reload() {
        Task {
            // inherited MainActor: parsing runs on main — the UI hangs
            items = parseHugeJSON()
        }
    }

    nonisolated func parseOffMain() async -> [Item] {
        parseHugeJSON()   // no isolation — runs on the cooperative thread pool
    }
}

1. The right way to move work off main — a nonisolated method or a dedicated actor, not detached: priority and task-locals are preserved.
2. When detached is honest — work independent of the launch context: logging, cache warming, kicking off from synchronous code with no actor around.

⚠️ Common mistake: curing "Task blocks the UI" by sprinkling detached through the code. You lose priority (inversion risk) and MainActor guarantees — when a nonisolated func would have sufficed.

Short answer: An actor serializes access to its mutable state: external calls go through await, and at most one method runs at a time. But actors are reentrant: at every await inside a method the actor may accept another call — state must be re-checked after an await. @MainActor is a global actor on top of the main thread, the home for UI-bound state.

In depth:

actor ImageCache {
    private var cache: [URL: Image] = [:]

    func image(for url: URL) async throws -> Image {
        if let cached = cache[url] { return cached }
        // suspension point: while we download, the actor serves other calls
        let image = try await download(url)
        // someone may have gotten here first — without a re-check we download twice
        cache[url] = image
        return image
    }
}

1. Isolation — data races on the actor's state are ruled out by the compiler, not by team discipline.
2. Reentrancy — deadlock protection at the price of interleaving: invariants read before an await are not guaranteed after it. The classic fix for double-downloading is a dictionary of in-flight Tasks: a repeat call awaits the already-running one.
3. nonisolated — for members that don't touch state (pure computation, Hashable): callable without await.

⚠️ Common mistake: "an actor is a mutex around the whole method." No: exclusivity holds only between suspension points. The actor's critical section ends at the very first await.

Short answer: Sendable is the marker "this value is safe to cross an isolation boundary": between actors, into a Task, across threads. In strict mode the compiler checks every such crossing: a non-Sendable value flying into another isolation domain is a compile error. The potential data race is caught before the app ever runs.

In depth:

struct User: Sendable { let id: Int }        // ✓ auto: value type of Sendable fields

final class Token: Sendable {                // ✓ final + let-only fields
    let value: String
    init(value: String) { self.value = value }
}

final class Cache: @unchecked Sendable {     // "trust me": synchronization is on you
    private let lock = NSLock()
    private var storage: [String: Data] = [:]
}

1. Sendable automatically — structs and enums made of Sendable fields, actors (by definition), final classes whose fields are all let of Sendable types.
2. Not Sendable — classes with var, closures capturing mutable state.
3. Honest fixes for strict-mode errors — make the model a value type; hide the state inside an actor; mark UI models @MainActor; @unchecked Sendable — only when the synchronization is genuinely written (a lock inside).

⚠️ Common mistake: silencing errors by sprinkling @unchecked Sendable. That's not a fix but a signed note saying "the races here are mine": the compiler stops checking exactly the spot where the race lived.

Short answer: A Timer is a RunLoop event source, not a standalone mechanism: for it to fire, a RunLoop must be running on the thread. The main thread always has one running; GCD pool threads don't spin one — the timer silently never fires.

In depth:

// ❌ silently broken: no RunLoop is running on a pool thread
DispatchQueue.global().async {
    Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { _ in
        print("tick")   // never
    }
}

// ✓ no RunLoop needed: DispatchSourceTimer lives on a queue
let timer = DispatchSource.makeTimerSource(queue: .global())
timer.schedule(deadline: .now() + 1, repeating: 1)
timer.setEventHandler { print("tick") }
timer.resume()   // and keep a strong reference to timer

1. RunLoop — the "wait for event → handle → sleep" cycle serving timers, perform-selectors, and some old-API delegates (NSStream, legacy URLConnection).
2. Modern replacements — DispatchSourceTimer, Task.sleep in a loop, AsyncTimerSequence — none of them need a RunLoop.
3. The second classic question — modes — scheduledTimer attaches the timer in .default mode, but during a scroll the main RunLoop switches to .tracking: the timer freezes. The cure: RunLoop.main.add(timer, forMode: .common).

⚠️ Common mistake: "fixing" a background timer with RunLoop.current.run() — and occupying the thread forever in a loop with no exit condition. For periodic work, DispatchSourceTimer is simpler and safer.