We are seeing this in our app too. We've had almost 3000 crashes since the 19th and this is totally blowing up our crash rate. (It is normally much, much lower.) We can't just remove the willSpeakRangeOfSpeechString callback, as we use this for highlighting the text as it is read. I filed FB8978383 on Friday. Please, please fix whatever resource file you broke, Apple.

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.