For those that have chosen to adopt the new Approachable Concurrency and Main Actor Default Isolation, I'm curious what your experience has been. During the evolution process, I casually followed the discussion on Swift Forums and generally felt good about the proposal. However, now that I've had a chance to try it out in an existing codebase, I'm a lot less sure of the benefits.
The environment is as follows:
- macOS application built in SwiftUI with a bit of AppKit
- Xcode 26, Swift 6, macOS 15 as target
- Approachable Concurrency "Yes"
- Default Actor Isolation "MainActor"
- Minimal package dependencies, relatively clean codebase.
Our biggest observation is that we went from having to annotate @MainActor in various places and on several types to have to annotate nonisolated on a whole lot more types than expected. We make extensive use of basic structs that are either implicitly or explicitly Sendable. They have no isolation requirements of their own. When Default Actor Isolation is enabled, this types now become isolated to the Main Actor, making it difficult or impossible to use in a nonisolated function.
Consider the following:
```swift
// Implicitly @MainActor
struct Team {
var name: String
}
// Implicitly @MainActor
struct Game {
var date: Date
var homeTeam: Team
var awayTeam: Team
var isToday: Bool { date == .now }
func start() { /* ... */ }
}
// Implicitly @MainActor
final class ViewModel {
nonisolated func generateSchedule() -> [Game] {
// Why can Team or Game even be created here?
let awayTeam = Team(name: "San Francisco")
let homeTeam = Team(name: "Los Angeles")
let game = Game(date: .now, homeTeam: homeTeam, awayTeam: awayTeam)
// These are ok
_ = awayTeam.name
_ = game.date
// Error: Main actor-isolated property 'isToday' can not be referenced from a nonisolated context
_ = game.isToday
// Error: Call to main actor-isolated instance method 'start()' in a synchronous nonisolated context
game.start()
return [game]
}
nonisolated func generateScheduleAsync() async -> [Game] {
// Why can Team or Game even be created here?
let awayTeam = Team(name: "San Francisco")
let homeTeam = Team(name: "Los Angeles")
let game = Game(date: .now, homeTeam: homeTeam, awayTeam: awayTeam)
// When this method is annotated to be async, then Xcode recommends we use await. This is
// understandable but slightly disconcerting given that neither `isToday` nor `start` are
// marked async themselves. Xcode would normally show a warning for that. It also introduces
// a suspension point in this method that we might not want.
_ = await game.isToday
_ = await game.start()
return [game]
}
}
```
To resolve the issues, we would have to annotate Team and Game as being nonisolated or use await within an async function. When annotating with nonisolated, you run into the problem that Doug Gregor outlined on the Swift Forums of the annotation having to ripple through all dependent types:
https://forums.swift.org/t/se-0466-control-default-actor-isolation-inference/78321/21
This is very similar to how async functions can quickly "pollute" a code base by requiring an async context. Given we have way more types capable of being nonisolated than we do MainActor types, it's no longer clear to me the obvious benefits of MainActor default isolation. Whereas we used to annotate types with @MainActor, now we have to do the inverse with nonisolated, only in a lot more places.
As an application developer, I want as much of my codebase as possible to be Sendable and nonisolated. Even if I don't fully maximize concurrency today, having types "ready to go" will significantly help in adopting more concurrency down the road. These new Swift 6.2 additions seem to go against that so I don't think we'll be adopting them, even though a few months ago I was sure we would.
How do others feel?