When would you choose a Swift actor over a serial DispatchQueue?

Why interviewers ask this

This question reveals whether you understand concurrency as a design choice instead of a syntax choice. A strong answer connects safety, readability, interoperability, and migration cost.

Strong answer structure

• Start with actor as a language-enforced isolation boundary for mutable state.
• Contrast that with a serial DispatchQueue, which protects state by team discipline and calling convention.
• Explain that actors usually make intent clearer in new Swift concurrency code, while queues can still be practical around older callback-based APIs.

Example

actor ImageCache {
    private var storage: [URL: UIImage] = [:]

    func image(for url: URL) -> UIImage? {
        storage[url]
    }

    func insert(_ image: UIImage, for url: URL) {
        storage[url] = image
    }
}

Tradeoffs to mention

1. Actors improve correctness and make data ownership easier to explain.
2. Dispatch queues still show up when bridging legacy code or coordinating non-Sendable dependencies.
3. Actor reentrancy matters, so some invariants still need careful reasoning.

If your answer sounds like "actors are newer so I use them," it will feel shallow. Tie the choice back to ownership and safety.