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.
