Okay, I have found a fix. Thank you all for taking your time in trying to helping me out. And a special thanks to the user that created this stack overflow answer: https://stackoverflow.com/a/67626393 It gave me the inspiration I needed to fix the issue. Here is a link to a branch of my example with the fix applied: https://github.com/martincapello/custom-event-loop-issue/tree/fixed

I think that nobody is focusing in the actual issue that is demonstrated here: https://github.com/martincapello/custom-event-loop-issue Let's put aside the UI framework discussion, and which approach you think is convenient to tackle it, and try to focus in the actual issue. In the example I did, I'm not doing anything fancy. I'm just getting the events generated by the system and then sending it to the application. So, intuitively, I thought that that should work, because I'm not doing nothing more that passing the messages (besides doing some logging for debugging, I'm not doing anything else). Then, why there is a particular case where this doesn't work as expected? All the rest seems to work great, but why does happen what I describe when the window is in fullscreen? If I'm not doing anything else than passing the events I receive to the application. And well, the answer seems to be because AppKit is doing something else in private methods to make it work, and since in my example I don't have (easy) access to that logic, I can't get rid of that issue. IMO it seems more like an AppKit's design flaw than anything else.

After some digging, I can tell you that it is not possible to just override the sendMessage method. The framework is intended to offer a cross-platform way to get the system's event queue and then build an event loop upon it. So we must use the nextEventMatchingMask to achieve that. If we just override sendEvent, then the framework user could not build an event loop, because once the framework calls NSApp.run then the main thread would block and the user looses control over the event loop. Will try to figure out a solution, thank you anyway. If someone of the developer's community has any idea to share, it would be great as well.

Hi Kevin, First of all, thank you for your feedback! Also, I want to clarify something, I'm not the author of the LAF framework (my brother David is) so there are a lot of design decisions that I'm not fully aware of, so I will ask him and invite him to participate in this thread. Broadly speaking, a library like this generally functions in one of two ways: As far as I can tell, the goal of the library is offering a standardized implementation, but trying to take advantage of some native features when needed. For instance, why would I re-implement the full screen feature if I can use the native one? Well, at least that's what I thought at first. But, I'm sure now you are wondering this again: what led you to override "run" at all? As I said, this was a design choice made by my brother, so I'm not aware of all the reason behind it, I'm pretty sure there are good reasons though. All I have to do is fixing this issue I'm reporting...after struggling quite a bit to make it work is that I've finally decided to try to get help from you. However, I do have the freedom to try to modify/improve LAF framework, so I'm going to see if I can just override the sendEvent method and avoid using nextEventMatchingMask as you suggested. This will lead me to one of two possibilities: Got a viable implementation Realize about the reasons why we needed nextEventMatchingMask I don't know if this is the exactly cause, but NSApplication.run's implementation creates and configures several private objects before it starts it's event loop and it also calls setWindowsNeedUpdate: (as well as other private methods) as it process events . Either or both of those could be causing the behavior you're seeing. Tried calling setWindowsNeedUpdate and didn't make any difference, I'm sure that we are missing some logic inside those private methods. I just wanted to know if maybe we were missing something else. For instance, if we don't call finishLaunching method we got undesired behavior as well, so I wanted to discard that we are missing something like this. Again, thank you for your help.