My experience with Swift 6 strict concurrency so far doesn't match my understanding of implicit MainActor isolation semantics. This is a cross-post from StackOverflow. I will link answers between both forums. TL;DR Build succeeds when testing a struct declared in the test module, but fails when the struct is moved to the main module: Main actor-isolated property … cannot be accessed from outside the actor. Steps to reproduce Open up Xcode 26 beta 2 on macOS 26 (probably also ok on current stables). Create a new Swift app with Swift testing, no storage. Call it WhatTheSwift. Set the Swift Language Version on all three targets to Swift 6. Update the default test file to be this: import Testing @testable import WhatTheSwift struct WhatTheSwiftTests { @Test func example() async throws { let thing = Thing(foo: "bar") #expect(thing.foo == "bar") } } struct Thing { let foo: String } That should build fine, and the tests should pass. Now, move the Thing declaration into its own Thing.swift file in the WhatTheSwift module, and try running the test again. You should see this: Observations Marking the test @MainActor allows the test to pass, suggesting the compiler actually wants to isolate Thing.foo to the main actor. My question Why? And why only when Thing is in a different module?

I've turned on Swift 6 language mode and noticed that during runtime Xcode gives this warning for a new widget (iOS 17.2): warning: data race detected: @MainActor function at TestWidgetExtension/TestWidget.swift:240 was not called on the main thread struct TestWidget: Widget { let kind: String = "TestWidget" var body: some WidgetConfiguration { AppIntentConfiguration( kind: kind, intent: ConfigurationAppIntent.self, provider: Provider() ) { entry in // LINE 240 TestWidgetEntryView(entry: entry) .containerBackground(Color.white, for: .widget) } } } Is there any way to solve this on my side? Thank you!

Hello, I'm trying to subscribe to AVPlayerItem status updates using Combine and it's bridge to Swift Concurrency – .values. This is my sample code. struct ContentView: View { @State var player: AVPlayer? @State var loaded = false var body: some View { VStack { if let player { Text("loading status: \(loaded)") Spacer() VideoPlayer(player: player) Button("Load") { Task { let item = AVPlayerItem( url: URL(string: "https://sample-videos.com/video321/mp4/360/big_buck_bunny_360p_5mb.mp4")! ) player.replaceCurrentItem(with: item) let publisher = player.publisher(for: \.status) for await status in publisher.values { print(status.rawValue) if status == .readyToPlay { loaded = true break } } print("we are out") } } } else { Text("No video selected") } } .task { player = AVPlayer() } } } After I click on the "load" button it prints out 0 (as the initial status of .unknown) and nothing after – even when the video is fully loaded. At the same time this works as expected (loading status is set to true): struct ContentView: View { @State var player: AVPlayer? @State var loaded = false @State var cancellable: AnyCancellable? var body: some View { VStack { if let player { Text("loading status: \(loaded)") Spacer() VideoPlayer(player: player) Button("Load") { Task { let item = AVPlayerItem( url: URL(string: "https://sample-videos.com/video321/mp4/360/big_buck_bunny_360p_5mb.mp4")! ) player.replaceCurrentItem(with: item) let stream = AsyncStream { continuation in cancellable = item.publisher(for: \.status) .sink { if $0 == .readyToPlay { continuation.yield($0) continuation.finish() } } } for await _ in stream { loaded = true cancellable?.cancel() cancellable = nil break } } } } else { Text("No video selected") } } .task { player = AVPlayer() } } } Is this a bug or something?

When creating a new project in Xcode 26, the default for defaultIsolation is MainActor. Core Data creates classes for each entity using code gen, but now those classes are also internally marked as MainActor, which causes issues when accessing managed object from a background thread like this. Is there a way to fix this warning or should Xcode actually mark these auto generated classes as nonisolated to make this better? Filed as FB13840800. nonisolated struct BackgroundDataHandler { @concurrent func saveItem() async throws { let context = await PersistenceController.shared.container.newBackgroundContext() try await context.perform { let newGame = Item(context: context) newGame.timestamp = Date.now // Main actor-isolated property 'timestamp' can not be mutated from a nonisolated context; this is an error in the Swift 6 language mode try context.save() } } } Turning code gen off inside the model and creating it manually, with the nonisolated keyword, gets rid of the warning and still works fine. So I guess the auto generated class could adopt this as well? public import Foundation public import CoreData public typealias ItemCoreDataClassSet = NSSet @objc(Item) nonisolated public class Item: NSManagedObject { }

I have the following struct doing some simple tasks, running a network request and then saving items to Core Data. Per Xcode 26's new default settings (onisolated(nonsending) & defaultIsolation set to MainActor), the struct and its functions run on the main actor, which works fine and I can even safely omit the context.perform call because of it, which is great. struct DataHandler { func importGames(withIDs ids: [Int]) async throws { ... let context = PersistenceController.shared.container.viewContext for game in games { let newGame = GYGame(context: context) newGame.id = UUID() } try context.save() } } Now, I want to run this in a background thread to increase performance and responsiveness. So I followed this session (https://developer.apple.com/videos/play/wwdc2025/270) and believe the solution is to mark the struct as nonisolated and the function itself as @concurrent. The function now works on a background thread, but I receive a crash: _dispatch_assert_queue_fail. This happens whether I wrap the Core Data calls with context.perform or not. Alongside that I get a few new warnings which I have no idea how to work around. So, what am I doing wrong here? What's the correct way to solve this simple use case with Swift 6's new concurrency stuff and the default main actor isolation in Xcode 26? Curiously enough, when setting onisolated(nonsending) to false & defaultIsolation to non isolating, mimicking the previous behavior, the function works without crashing. nonisolated struct DataHandler { @concurrent func importGames(withIDs ids: [Int]) async throws { ... let context = await PersistenceController.shared.container.newBackgroundContext() for game in games { let newGame = GYGame(context: context) newGame.id = UUID() // Main actor-isolated property 'id' can not be mutated from a nonisolated context; this is an error in the Swift 6 language mode } try context.save() } }

I've been testing my open source libraries with Swift 6.2 and the new Default Actor Isolation concurrency build setting set to MainActor (with Complete strict concurrency turned on). My library Destinations uses protocols extensively, often applying conformance to foundational Swift protocols like Hashable and Identifiable. Many of these basic protocols are not flagged as running on the @MainActor in Beta 1, leading to situations like this: Given this example code: public protocol Contentable: Identifiable { var id: UUID { get } } final class ContentModel: Contentable { let id: UUID = UUID() } I get the warning: Multiline Conformance of 'ContentModel' to protocol 'Contentable' crosses into main actor-isolated code and can cause data races; this is an error in the Swift 6 language mode The fix it suggests is to put a @MainActor before the Contentable protocol declaration in ContentModel, which seems to be a new attribute configuration in Swift 6.2. This solves the warning, but would create a lot of extra noise across the codebase. Was it an oversight or a temporary omission that protocols like Hashable and Identifiable do not run on @MainActor by default, or is there some other reason they are excluded? Considering how often protocols in our code may conform to foundational protocols like this, it seems at odds to the MainActor mode of the Default Actor Isolation setting given that it was created to make concurrency easier and less boilerplate to implement.

I'm running into a seemingly unsolvable compile problem with the new Xcode 26 and Swift 6.2. Here's the issue. I've got this code that was working before: NSAnimationContext.runAnimationGroup({(context) -> Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }, completionHandler: { self.endIgnoreFrameChangeEvents() }) It's very simple. The clipView is a scrollView.contentView, and "animated" is a bool, and p is an NSPoint It captures those things, scrolls the clip view (animating if needed) to the point, and then calls a method in self to signal that the animation has completed. I'm getting this error: Call to main actor-isolated instance method 'endIgnoreFrameChangeEvents()' in a synchronous nonisolated context So, I don't understand why so many of my callbacks are getting this error now, when they worked before, but it is easy to solve. There's also an async variation of runAnimationGroup. So let's use that instead: Task { await NSAnimationContext.runAnimationGroup({(context) -> Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }) self.endIgnoreFrameChangeEvents() } So, when I do this, then I get a new error. Now it doesn't like the first enclosure. Which it was perfectly happy with before. Here's the error: Sending value of non-Sendable type '(NSAnimationContext) -> Void' risks causing data races Here are the various overloaded definitions of runAnimationGroup: open class func runAnimationGroup(_ changes: (NSAnimationContext) -> Void, completionHandler: (@Sendable () -> Void)? = nil) @available(macOS 10.7, *) open class func runAnimationGroup(_ changes: (NSAnimationContext) -> Void) async @available(macOS 10.12, *) open class func runAnimationGroup(_ changes: (NSAnimationContext) -> Void) The middle one is the one that I'm trying to use. The closure in this overload isn't marked sendable. But, lets try making it sendable now to appease the compiler, since that seems to be what the error is asking for: Task { await NSAnimationContext.runAnimationGroup({ @Sendable (context) -> Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }) self.endIgnoreFrameChangeEvents() } So now I get errors in the closure itself. There are 2 errors, only one of which is easy to get rid of. Call to main actor-isolated instance method 'animator()' in a synchronous nonisolated context Call to main actor-isolated instance method 'setBoundsOrigin' in a synchronous nonisolated context So I can get rid of that first error by capturing clipView.animator() outside of the closure and capturing the animator. But the second error, calling setBoundsOrigin(p) - I can't move that outside of the closure, because that is the thing I am animating! Further, any property you're going to me animating in runAnimationGroup is going to be isolated to the main actor. So now my code looks like this, and I'm stuck with this last error I can't eliminate: let animator = clipView.animator() Task { await NSAnimationContext.runAnimationGroup({ @Sendable (context) -> Void in context.duration = animated ? 0.5 : 0 animator.setBoundsOrigin(p) }) self.endIgnoreFrameChangeEvents() } Call to main actor-isolated instance method 'setBoundsOrigin' in a synchronous nonisolated context There's something that I am not understanding here that has changed about how it is treating closures. This whole thing is running synchronously on the main thread anyway, isn't it? It's being called from a MainActor context in one of my NSViews. I would expect the closure in runAnimationGroup would need to be isolated to the main actor, anyway, since any animatable property is going to be marked MainActor. How do I accomplish what I am trying to do here? One last note: There were some new settings introduced at WWDC that supposedly make this stuff simpler - "Approchable Concurrency". In this example, I didn't have that turned on. Turning it on and setting the default to MainActor does not seem to have solved this problem. (All it does is cause hundreds of new concurrency errors in other parts of my code that weren't there before!) This is the last new error in my code (without those settings), but I can't see any way around this one. It's basically the same error as the others I was getting (in the callback closures), except with those I could eliminate the closures by changing APIs.

If I set my build settings "default actor isolation" to MainActor, how do my @ModelActor actors and model classes need to look like ? For now, I am creating instances of my @ModelActor actors and passing my modelContext container and processing all data there. Everything stays in this context. No models are transferred back to MainActor. Now, after changing my project settings, I am getting a huge amount of warnings. Do I need to set all my model classes to non-isolated and the @ModelActor actor as well? Is there any new sample code to cover this topic ... did not find anything for now. Thanks in advance, Marc