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).