I'm having this same issue, can't debug in the Xcode 12.5 simulator on macOS 11.4. It was working before, sigh. Filed an issue at FB9119051. Please fix, this is a major blocker! Normally when I have simulator debugging issues, the Safari Developer Preview has a fix already, but not this time.

Looks like Apple just published a fix. Safari Technology Preview build 125 just went live a few minutes ago, and it has the fix. If I use "Develop" from this build of Safari it works just fine. Download it here: https://developer.apple.com/safari/download/ It's the top item in the release 125 release notes: https://developer.apple.com/safari/technology-preview/release-notes/

Oh it's worse than that. Somehow I have an "Inline Comparison" view I am stuck in. Not only is it showing me line numbers, but it is showing me a comparison with what's in git (I guess). Ok I'll just have to figure out how to get out of this view. I miss the double-arrows button in the old version of Xcode to obviously toggle this sort of view on and off. Now I'm in this mode and can't find my way out.

FWIW I got out of it by selecting "Canvas" from the Editor menu. I figured it out by switching between my tabs and looking at what was checked in "Editor." None of the Editor modes had checkboxes by them, somehow, in the one tab that had the issue. Canvas was selected in the tabs that were working normally. Even after I switched to "Canvas" I still had to toggle line numbers (again) to get those to go away. But at least it isn't showing me my changes inline as i make them. That was borderline unusable. I'm not a new Xcode user, I've been using it for well over a decade. I've never been this confused - I still don't know what mode I was in or how I exactly got into it.

Submitted as feedback: FB11796550

Since the constant is marked as "var", couldn't I also do this if I wanted and just totally break the SDK? UIAccessibility.Notification.pageScrolled = UIAccessibility.Notification(rawValue: 12345)

Thanks! For now I'm using this just so I can get rid of the errors and move on. I'll back the changes out when your fix lands. fileprivate let pageScrolled = UIAccessibility.Notification(rawValue: 1009) fileprivate let layoutChanged = UIAccessibility.Notification(rawValue: 1001)

Another data point that NSAccessibilityElement should probably be MainActor: the UIKit counterpart, UIAccessibilityElement, is defined as @MainActor. For now I'm assuming that NSAccessibilityElement should also be marked MainActor and just isn't yet. I've fixed my issues with MainActor.assumeIsolated in the places where my NSAccessibilityElement subclasses need main actor isolation. So far it looks like it is only used on the main thread so this is working for me, at least for now. I'd love confirmation of this by Apple fixing the SDK if this assumption is correct.

I found more of them in that same file. All the constants in extension UIAccessibilityTraits: extension UIAccessibilityTraits { public static var none: UIAccessibilityTraits

These are all fixed in Xcode 16 beta 3. Thanks!

Hey, that's brilliant! I'm going to do that, instead. Especially since I already have an implementation of init(frame: CGRect) that also inits my properties (in the same way as the default initializer did). Using a default value fixes the issue and reduces the code. This still feels like a Swift bug to me, but that fix works great.

The init() problem must have just been a bug. It's gone again in 16.0.beta6 which was just released today. The awakeFromNib problem is still there- I just moved all my initialization code to other places (view lifecyle calls). Most of it already is.

Just as an update - I took my changes back to Xcode 16.4 and got the same errors when I tried to use the asynchronous version of runAnimationGroup. So, I don't understand how I am supposed to use the async version of this method. Maybe the async version actually runs its closure on a thread? But back to the original error, which is the thing that started this all off: NSAnimationContext.runAnimationGroup({(context) -> Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }, completionHandler: { self.endIgnoreFrameChangeEvents() }) Call to main actor-isolated instance method 'endIgnoreFrameChangeEvents()' in a synchronous nonisolated context This is the error that I get in 6.2 / Xcode 26 that I wasn't getting before. I would expect all of these callback-based APIs to run their completion handlers on the main thread. It seems like maybe there's just a @MainActor missing in the definition of completionHandler: here? It didn't seem like this was necessary before Swift 6.2.

One more update- I was able to work around this for now just by tossing an assumeIsolated into the completion handler. Hopefully, Apple will eventually annotate all of these completion handlers as explicitly @MainActor, now that the Swift language has evolved and the completion handler isn't implicitly MainActor like it used to be. I'm still not sure how one would use the async version of this API, though. It either should have had its closure marked as @MainActor but didn't, or if it DOES need to be nonisolated (because it runs on a thread), that means for animating view properties we have to use the callback version of this API. Here is my final, working (for now) code. I hope Apple annotates these completion closures better so the original code continues to work. NSAnimationContext.runAnimationGroup({(context) -> Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }, completionHandler: { MainActor.assumeIsolated { self.endIgnoreFrameChangeEvents() } })

The feedback number was: FB19181123 It seems to be fixed in the beta 5 developer previews! Verified in Xcode beta 5 iOS 26 simulator, Tahoe beta 5 in a virtual buddy VM, and on an iOS device running the beta 5 release. We've had users on the public beta hitting this as well in our app. Hopefully public beta 2 will be out shortly? They usually follow pretty closely after the developer releases.