Swift Concurrency Changes How You Hire iOS Engineers

WWDC 2021 was ten weeks ago and most iOS engineering orgs have already started thinking about how to use async/await in production. Almost none of them have started thinking about how it changes their hiring loop. That gap is going to be expensive.

The async/await rollout, structured concurrency, the Actor model, and the long-term direction Ben Cohen laid out in the Swift Concurrency Roadmap last October all point at the same destination: data races eliminated by the compiler. That destination is a fundamentally different language than the one the senior iOS engineers in your interview pipeline learned. The vocabulary is new. The mental model is new. The interview questions most teams have been asking for a decade now test for a body of knowledge that is becoming legacy.

The teams that update their hiring rubrics in the next six months are going to find themselves with engineers who can pattern-match Swift Concurrency idioms in code review and design conversations. The teams that don't are going to keep hiring engineers who answer "how would you make this thread-safe" with "wrap it in a serial dispatch queue" and miss the fact that the right 2021 answer is "make it an actor."

What WWDC 2021 actually shipped

I want to be precise about what changed, because the discourse keeps collapsing it into "Swift got async/await."

The language got async/await. The language also got structured concurrency: tasks, task groups, cancellation propagation, the rule that an async function's child tasks finish before it returns. The language got Actors: a new type kind that owns its mutable state and forces cross-actor access through await. The language got Sendable: a compile-time marker for "this type is safe to send across concurrency domains." Each of these is a distinct concept, with its own rules, and none of them maps cleanly onto the GCD model.

Apple's Session 10132, "Meet async/await in Swift", is the canonical introduction. The session explicitly contrasts a roughly twenty-line completion-handler fetchThumbnail with a six-line async version, then walks through what "suspension" actually means: the thread is freed, not blocked, the caller's state machine is compiler-managed. The cognitive jump is from "I am scheduling work onto a queue" to "I am writing code that the compiler is going to slice into pieces and resume at specific points."

SE-0306, the Actors proposal, is the deeper change. The actor type kind makes shared mutable state safe by language construction. You cannot access an actor's mutable state from outside the actor without await. You cannot have a data race on the actor's own state because the compiler refuses to compile a missed lock. (You can still have logic races caused by reentrancy and you can still have Sendable holes; those are real, and we'll get to them.) This is what Cohen's roadmap is pointing at when it says "data races eliminated by the compiler." That is the actor model arriving in mainstream language design, twenty years after Erlang got there first.

The community translation arrived inside 24 hours of the WWDC sessions. Donny Wals's "WWDC Notes: Protect mutable state with Swift actors" from June 8 lands the practitioner version: locks, atomics, and serial queues all required developer discipline; actors move that responsibility to the compiler. John Sundell's June 21 piece, "Connecting async/await to other Swift code", is the migration-shaped framing every senior engineer needs: "like with all major technology transitions, it's going to take a while for us to get there." The community already understands this is a multi-year migration, not a flag flip.

The hiring rubric problem

Look at the typical senior iOS interview loop circa Q1 2021. There is almost always a concurrency question. It usually looks like one of these:

"Write a thread-safe in-memory cache."
"What's the difference between a serial and a concurrent dispatch queue?"
"How does GCD's QoS system work?"
"When would you use DispatchSemaphore?"

These are good questions for the language Swift was in March 2021. They are increasingly bad questions for the language Swift will be in 2022 and 2023. A candidate who is fluent in async/await and Actors will answer them, but the answer will be a polite history lesson, not a demonstration of the skill that matters for their next two years of work. A candidate who is still GCD-fluent and Actor-unfamiliar will pass these questions and will then spend their first six months at your company writing code that has to be rewritten when the team adopts Swift Concurrency in earnest.

The harder problem: most of your senior interviewers do not know Swift Concurrency well enough to write the new version of these questions yet. The interview rubric will lag the actual skill the team needs by a full cycle or two, because the interviewers themselves are mid-migration.

What a 2021 Swift Concurrency interview question looks like

I have been thinking about this in concrete terms because I will be hiring iOS engineers in Q4. Here is the shape of the questions I am writing:

The actor isolation question. Given a class that wraps a piece of mutable state with a serial dispatch queue, rewrite it as an actor and walk through the consequences. What changes about how callers use it? What new failure modes does the actor version have that the GCD version didn't? (Actor reentrancy is the new sharp edge: an await inside an actor method lets another task interleave on the same actor, so invariants held only across non-suspended code can break in ways a serial dispatch queue would have prevented. The candidate should bring this up unprompted. If they don't, that's information.)

The structured-concurrency question. Given a function that fires off three completion-handler API calls in parallel and aggregates the results, rewrite it with async let or a task group. Walk through what happens to cancellation. (The point is that GCD didn't propagate cancellation cleanly and structured concurrency does. The candidate should land on that.)

The Sendable question. Given a struct that gets passed across actor boundaries, walk through what Sendable does and what would happen if the struct contained a reference type. (Tests whether the candidate understands the type system implications of concurrency safety, not just the syntax.)

The migration question. Given an existing API that uses completion handlers, write the async wrapper. Use withCheckedContinuation if the underlying API doesn't throw, withCheckedThrowingContinuation if it does. (Tests whether they can navigate the bridge between regimes, which is the actual day-to-day work of 2022.)

None of these questions are about syntax. All of them test the new mental model: concurrency as a type-system axis, not a runtime concern.

The team-mix problem

Here is the part that's harder to talk about than the interview rubric.

The engineers who know GCD cold are not the engineers who pattern-match Actor isolation. Those are two different skills, and the engineers strong in the first are not automatically strong in the second. You are going to discover, when you start using Swift Concurrency in production, that your existing seniors split. Some of them love the new model and become the in-team experts inside a quarter. Some of them quietly resist it, keep writing GCD-flavored code with async wrappers, and become the people whose PRs need extra review because they're using the new tools wrong.

This is normal. Every major language shift does this. RxSwift did this seven years ago; I wrote about which RxSwift patterns actually held up in 2019, and the engineers who got RxSwift cold were not the same engineers who had been strong in pre-Rx callback patterns. The senior-engineer pool re-sorted itself around the new model.

The same re-sort is going to happen with Swift Concurrency, and it is going to happen on a faster timeline because the compiler is doing more of the enforcement this time. The engineers who develop Swift Concurrency intuition fast will compound their advantage quarter over quarter. The engineers who don't will increasingly find themselves on the wrong side of code review conversations.

This is a team-design problem as much as a hiring problem. You need to give your senior engineers time and structured exposure to Swift Concurrency. Not as a "learn it in your free time" expectation. As an explicit Q3 platform investment, with paired learning and real production migrations.

A Q4 plan for iOS hiring

If I were running an iOS team this quarter, the actions I would take before the next hiring round:

Rewrite the senior concurrency question. Replace whatever GCD-flavored question is in the current rubric with one of the four shapes above. Write the rubric down. Get two senior engineers to dry-run the question on each other before it goes into a real loop.

Train the interviewers. The interviewers need to be able to evaluate the new answers. Two hour-long sessions on actor isolation and structured concurrency, with the rubric reviewed at the end, is the minimum.

Update the leveling guide. "Strong understanding of GCD" was a senior-iOS leveling expectation in 2019 and 2020. Replace it with "Strong understanding of Swift Concurrency, with the ability to design actor-based architectures and reason about reentrancy and Sendable conformance." If your leveling guide still references GCD as the canonical concurrency primitive, it is dated.

Don't penalize candidates who haven't shipped Swift Concurrency yet. Almost nobody has shipped meaningful Swift Concurrency in production yet. Test for the mental model and migration fluency, not for shipped code. The candidates who can talk through the type-system implications and the actor-vs-GCD trade-offs cleanly are the ones who will ship it well in 2022, regardless of whether they've done it in 2021.

Where I land

Swift Concurrency is the most consequential Swift release since the original 2014 language. The hiring loop is where the gap between the old language and the new one will compound or close. The teams that update their interview rubric in Q4 2021 will be hiring engineers fluent in the new model going into 2022, exactly the year their production codebases will need that fluency. The teams that don't will be hiring engineers calibrated to a language that is being deprecated underneath them.

The async/await keyword is the easy part. The hiring rubric is the hard part. Update your interview questions this quarter.