My (Concurrency) Wishlist for Xcode 27

In a recent exchange with Matt on Mastodon, I realised it's been a while since I had a chance to write about Swift Concurrency.

Swift 6.2 comes a long way to alleviate the rough edges of the initial release and now I find myself using it comfortably.

I think the biggest friction at the moment, is awareness of what's going on in concurrency world while writing code. Think about it: what's going to happen here [where my cursor is] in terms of concurrency?

It would be awesome if future Xcode introduces some additional visual hints (either directly in the editor area, or somewhere in a Alt+Click dialog) which can help answer some of these questions.

During summer, I was re-watching older WWDC talks and there is this one back from 2022 when Swift concurrency was being introduced.

The presenters walk the viewer through a few debugging sessions in order to identify performance issues related to blocking the MainActor, parallelisation of tasks and actor contention. These are well-chosen examples because they will probably appear in large number of applications (e.g. any app loading data from the network or disk), etc.

While using Instruments is always a good idea (and current Xcode 26 has amazing tooling for observing concurrency related issues), there are several opportunities to improve this even more in the editor itself. let's break down some features Xcode could introduce in order to make it easier to anticipate issues, before they become a bug for the instruments.

With "approachable concurrency", there are a number of compiler settings which affect how concurrency works. These are configurable in Build Settings for Xcode projects or the Package.swift file for Swift Packages and may affect various aspects including:

• Inference of Sendable conformance
• Isolation of global variables
• Region isolation
• Default Actor Isolation (nonisolated vs. MainActor)

Since these can change per target (and also per Swift Package dependency), a developer needs to carefully study and map out these options in order to know where/how a current piece of code will be interpreted from concurrency point of view.

Xcode feature: Make it easy to see which actor the compiler will assign to the current function/variable/class/struct in the current scheme.

Functions defined within an `actor` usually run within that actor, unless they have some attributes (like @concurrent). It's always helpful to know which actors can run a specific snippet. There may be more than one and that is very helpful information which can also help me choose the best actor and attributes for my function.

Xcode feature: on which actor(s) is the current line going to run?

Listing all possibilities from the code base can be critical. I was recently working in app, which made use of @ModelActor for some background SwiftData handling. It was imported via @Environment and used in various views and functions both in their actors, as well as @concurrent. It would be amazing if I could just list all these "callers" so I can decide if my ModelActor choice was appropriate here, before it becomes bottleneck.

Xcode feature: which actor(s) / Tasks are going to await this function?

That's a good one. In Swift, we "await" async functions. Sometimes functions are defined as async, sometimes we "await" because they're on a different actor. It would be very helpful to know this proactively (visually) while writing or reading a code snippet.

In the WWDC talk I linked above, this is a main point that was the cause of the problem they were troubleshooting. When developing, it will be very interesting to be able to quickly tell:

• Xcode feature: is an await going to jump actors? (e.g. like the log() from the talk)
• Xcode feature: is an await waiting for a @concurrent function? Also, am I awaiting the current actor or another actor?

In the source editor, we can always see which functions are calling into the current method (based on source code analysis). With Swift concurrency and the fact that the "caller" may be in another target/SPM package and this subject to different concurrency settings, it will be awesome if the editor can also hint at some additional information at the point of "await":

• Xcode feature: is an await jumping to wait for an actor which is already being awaited in the call stack of the current method?
• Xcode feature: is the current code running in a detached Task?
• Xcode feature: Am I awaiting a method of the current actor in a Task that's started also in current actor? (which may hint at having needlessly added a Task {} to call a method in the same actor, among others)

These are just a few examples but you can imagine the kind of hints we're talking about here. It gets even more interesting when such info is presented for something calling into methods defined in a SPM (which may have different concurrency config than the current project).

I also posted this on the Swift Forums, for folks who may be interested in discussing some of the points below.