I have a SwiftUI-lifecycle Mac app that uses a standard NavigationSplitView. When it runs on macOS 26 Beta 3, I see invalid constraint messages in the debugger at launch and when I navigate around the app's UI: Since this app is 100% SwiftUI, I'm not adding my own constraints. The invalid constraint is always the same. This has happened on every beta of macOS 26 and DOES NOT happen on macOS 14 or 15. I've filed feedback reports with no answer. Has anyone else encountered this with the betas?

Has anyone else noticed that macOS Sequoia 15.5 has a regression in SwiftUI Table scrolling performance? I have complex Tables in a SwiftUI app and they scroll adequately on macOS 15.4.1 but hang, beachball, and stutter while scrolling on macOS 15.5. The exact same build is running in both cases. (I've even reduced the table to three simple columns of text and STILL fail to get entirely smooth scrolling on macOS 15.5.) It's like someone just fundamentally broke Table on macOS. Has anyone else encountered this?

Context I have a Mac app that runs from the status bar. When an NSStatusItem is clicked, I display an NSWindow rather than the standard NSMenu. Problem Before Sonoma, when the NSStatusItem was clicked I used the activate(ignoringOtherApps: true) API that is now deprecated to ensure that my application became the active app. On Sonoma, macOS now shows my window but does not activate the application, which means the user must click on the window before interacting with my UI. It also produces a very jarring experience when the user does click in the window, because the active application finally switches. Worst of all, the problem occurs only about 85% of the time. 15% of the time, the system activates my app when the UI is shown. I cannot nail down a pattern for it yet, but this jives with the AppKit release notes that suggest the system "may" activate my App. (If some stupid, over-engineered, machine-learning gobbldegook thinks it's worth doing, no doubt.) Question What is the solution here? How do I tell the system that my app NEEDS to become active when my NSStatusItem is selected because (A) that's what the user expects and (B) the alternative looks like macOS is broken? Attempts I have tried setting NSApplication.shared.setActivationPolicy() with both .accessory and even .regular (even though that adds a Dock icon and menubar) and the problem persists.

Whenever I switch away from a Nib file and then come back to it, Interface Builder "resets" its state. That is, the left-hand outlineView that shows the structure of an IB document collapses to a stupid "minimized" width and the canvas has scrolled away from the view/window I had selected before switching away from IB. This has been a constant issue in Xcode 13 and persists in Xcode 14 Beta 2. Is anyone else seeing this behavior? I have filed multiple Radars about it over the last year and not one has gotten a response (shocking, I know).