ARTICLE AD BOX
Xcode itself tells you:
Approachable concurrency "Enables upcoming features that aim to provide a more approachable path to Swift Concurrency: DisableOutwardActorInference, GlobalActorIsolatedTypesUsability, InferIsolatedConformances, InferSendableFromCaptures, and NonisolatedNonsendingByDefault." You can look up all of those under Swift Compiler - Upcoming Features.
And indeed if you toggle Approachable Concurrency on and off you can see those settings under Swift Compiler - Upcoming Features switch on and off with it.
Default actor isolation "Controls default actor isolation for unannotated code. When set to 'MainActor', @MainActor isolation will be inferred by default to mitigate false-positive data-race safety errors in sequential code."
It is unrelated (orthogonal) to any of the features listed in the previous paragraph.
The best thing moving forward, though, is to switch Swift Language Version to Swift 6, Approachable Concurrency to YES, and Default Actor Isolation to MainActor. The first of those will switch Strict Concurrency Checking to Complete, as well as turning on some of the same things that Approachable Concurrency turns on. You are now living in the modern world.
but disable "nonisolated(nonsending) by default", and also set default actor isolation to nonisolated
Well, don't do that. Whyever would you want to? But if you do, you do (and your setting is obeyed). In other words, Approachable Concurrency (and Swift 6) toggles some settings to YES, but you are free to toggle them to NO. There isn't any "conflict" behind the scenes; the scene, as it were, is exactly what you see in front of you.
541k98 gold badges951 silver badges1.3k bronze badges
3 Comments
Hmmm, so this section from avanderlee.com/concurrency/… is wrong? "Approachable Concurrency flips that experience around: your code can start from a single-threaded, @MainActor-by-default world"
2026-05-05T20:29:22.197Z+00:00
@HL666 – No, in that article, Antoine is absolutely right: The whole motivating idea behind Approachable Concurrency is that the vast majority of apps simply don’t need anything beyond main actor code that will occasionally (asynchronously) await some API call. For years, Swift has dragged us through broken glass of writing multithreaded code (Sendable types, region-based isolation, etc.), and this new paradigm acknowledges that for most apps, you just don’t need to go there. And, IMHO, nothing that matt wrote above is inconsistent with that. But I think he captured the mechanics well.
2026-05-05T23:51:51.007Z+00:00
@HL666 – Re when to use different “Default actor” settings, we should note that when you create a new app, Xcode defaults it to “MainActor” (because that’s a great default choice for most app code), but if you create a framework target within that app, its “Default actor” defaults to “nonisolated” (where you may well be creating non-UI services and might want to make more considered decisions about isolation). Both “Default actor” settings have their place: But for apps, as matt said, defaulting to main actor eliminates a ton of unnecessary headaches.
2026-05-06T00:03:09.87Z+00:00
Explore related questions
See similar questions with these tags.
![JSONEncoder.encode causes stack overflow crash (thread_chkstk_darwin) on iOS 26.3.1 only — deeply nested Codable model [closed]](https://stackoverflow.com/Content/Sites/stackoverflow/Img/apple-touch-icon@2.png?v=0f0cab681579)