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. This worked perfectly, so Apple decided to nuke it.
On Sonoma, macOS now shows my window but does not activate the application, which means the user must click on the NSStatusItem and then click again 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, but not when the user expected it. Both my window and the previously-active app suddenly redraw in different states. It's ugly.
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
How do I tell the system that my app NEEDS to become active when my NSStatusItem is clicked 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.
I had a similar issue where
NSApplication.shared.activate(ignoringOtherApps: true)doesn't consistently work, but it seems thatNSRunningApplication.current.activate(options: .activateIgnoringOtherApps)does