Normal，You won't encounter this problem，Until you need to write a background program...
We all know that macOS has a global Dock，All running programs will be displayed on this thing，But if your program is a menu bar applet，Or a...input method，Then you definitely don’t want the icon of this app to be displayed on the Dock，Because this kind of app needs to run continuously in the background。
At this time we can write in Info.plist LSBackgroundOnly Field，This app will run in the background，No Dock icon，It will not be displayed in the switch option of cmd+tab。This is what the drop grid input method does，This is also the configuration in Apple's official example-but this has long been accompanied by a problem，That is if your app still needs to display the necessary settings interface，Then this interface will always be at the bottom of all windows，That is，The window was blocked as soon as it popped up。Even，In addition to standard windows，Any other warning popups，All can't be displayed，Unless a standard window appears first，And the user clicked anywhere in the window...
The above premises have caused many problems，I have to embed another app as a special setting software for the drop-off input method，Then use xpc communication between the two，Really desperate。
Until today TIL，I found out that it can be used NSApplication.shared.setActivationPolicy(.accessory) Dynamically change your run level in the program，You can dynamically modify yourself to be ordinary regular mode，Or backstage prohibited mode。Obviously，I also understand by looking at the code name，It turns out that this background mode，Is deliberately disallowing pop-up windows。
|
1 2 |
/* The application does not appear in the Dock and may not create windows or be activated. This corresponds to LSBackgroundOnly=1 in the Info.plist. This is also the default for unbundled executables that do not have Info.plists. */ case prohibited = 2 |
Obviously，If you declare that the program is a background program，Then all of its windows can't get the focus，I always thought this problem was a bug of macOS😅
Then，Is there any other plan? Really have，In addition to the two modes above，macOS actually provides a mode between the two，No icon is displayed like a background program，It can also get focus when necessary and pop-up windows like ordinary programs：
|
1 2 |
/* The application does not appear in the Dock and does not have a menu bar, but it may be activated programmatically or by clicking on one of its windows. This corresponds to LSUIElement=1 in the Info.plist. */ case accessory = 1 |
When necessary, the operating mode of the program is dynamically switched to accessory .。
of course，If the code is too troublesome，We can also directly change Info.plist，The LSBackgroundOnly ，To LSUIEelement ，.。
Original article written by Gerber drop-off：R0uter's Blog » Three operating modes of macOS application
Reproduced Please keep the source and description link：https://www.logcg.com/archives/3531.html
Hello blogger, I have this problem now：normal logic is，I click the close button of the main interface window，Then DOCK disappears，But a new window pops up，Prompt to run in the background。NSApplication.sharedApplication is used().setActivationPolicy（0x1），But after executing this string of code，All my windows are gone，how to solve。
I am using the SWT framework of JAVA。
I have never used SWT framework，But you try to use alert instead of window，Or set the window to be fixed at the front，Just that popup level。In theory, this should not happen。
In addition, you check whether the incoming 0x1 is correct，I'm not sure how SWT converts pass-by-value，It is possible to convert to an unrecognized value and cause unexpected behavior。
Currently no problem on M1 processor 13.1，On intel version 10.15.7，I first execute setActivationPolicy(0x1)，Then a pop-up window (just a window)，Appears and disappears immediately。Then I loop to judge the return value of setActivationPolicy (0x1)，when the return value is true，popup will be normal。Is it because the bottom layer of setActivationPolicy (0x1) is multi-threaded，It caused him to execute after my pop-up window was generated。(but even then，It should also put the pop-up window at the bottom，rather than a direct flash)
Oh oh，that does，None of these APIs take effect in real time，you try to wait a second，should be fine。I did have a similar problem。
Is there any better solution，because the user's device may be poor，may also be good，I can't determine how long to wait
There is an idea to monitor the running status of the app，Such as entering the background or something? Or look at the results of the API for getting this status，It will pop up after it takes effect。Although I figured out the situation，later for other reasons，I didn't use it，My input method setting window is still implemented using a separate app。
thanks for your answer，Your idea really works。but i have a question，When monitoring the status of the APP，is it possible，app is closed，But setActivationPolicy has not been executed yet (not encountered yet)。Then I judge that the app status is closed，opened the popup，Then setActivationPolicy executes，then my popup will be closed by it again。
So I started a new thread，Determine whether the return value of setActivationPolicy is true，yes，It means that his execution is over，I just open the popup。In this way, my pop-up window will always be executed after setActivationPolicy，will not be closed。
Another question is，I don't know why in my program，After executing setActivationPolicy(1)，will close all my windows，His effect should not be to close the DOCK，And bring all windows to the bottom?
it's hidden...he just doesn't show it，not closed for you。
In addition, set it to 1 to both hide and allow display，So the switch of the window can only be controlled by yourself。
Your situation🤔I don't know either，sorry ha。
Excuse me ：How to enter LSBackgroundOnly in Info.plist
Add a field directly at the root level，key is LSBackgroundOnly，Type is bool，Value is 1 or yes